Dmitry Arefiev

@A.M. Hoornweg, I created and attached experimental patch. Please, try it and let me know. If all is OK, then I will include it into next 10.3 update.

grid.patch

http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Using_SQLite_with_FireDAC#Adjusting_FireDAC_Mapping

Read sentence "For an expression in a SELECT list ..."

Is it bad to use official DLL ? Several questions:

* are you limited in distributing capabilities of this DLL (license, space, what ever) ?

* who will support you, when something is broken, and you are using non-official connectivity ?

* with whom you you can discuss your connectivity problems on INet, if you are using some from 3d party ?

* how long will live your software, when 3d party provider is out of business, and DLL "insides"/protocol are changed ?

This is IProviderSupport or IProviderSupportNG.

Yes, it is.

This issue was (most probably) fixed in 10.2.2. Your workaround is almost correct.

You can do, when both conditions are met:

* TOracleDataSet and TgQuery both are inherited from TDataSet

* and properly implement IProviderSupport methods:

procedure Form1.Proc1( aQry : TDataSet );
begin
  ...
  aQry.Close;
  (aQry as IProviderSupport).PSSetCommandText('select * from xyz');
  aQry.Open;
  ...
end;

3 hours ago, Stefan Glienke said:

But then on the other hand break things every other version just because... 

 Could you please provide some tickets to better understand what and where.

https://www.wireshark.org/

https://www.telerik.com/fiddler

In this case I would try to capture HTTP packets sent from 10.1.2 and 10.2.1 clients. And will try to understand what is the difference between them, which may lead to this failure ...

This is not related to REST client. But is related to REST server, which is accessing to InterBase server. And due to some reason the database specified in FireDAC connection parameters is not available. Start from checking your InterBase interbase.log ...

The patch and instruction is published there:

https://quality.embarcadero.com/browse/RSP-23656

@RDPasqua, depends on RAD Studio version. In 10.3 standard JSON library is much faster and reliable.

This issue is fixed in 10.3 Rio. And more is comming in Updates.

If to stay with 10.1, then search and install IDE HotFix Pack.

GetValue (@Rec)

https://quality.embarcadero.com/browse/RSP-20857

Will be fixed in 10.3 Update 1

https://quality.embarcadero.com/browse/RSP-20349

No sense, as in the trial to find 100% working guessing

It is impossible to decide for 100%. But possible to guess taking into account ThousandSeparator and DecimalSeparator. It will work in 95.38% of the cases. All other - up to the user.

On 1/31/2019 at 7:47 PM, David Schwartz said:

This has to do entirely with how CLOBs are stored vs. VARCHAR2's. The data is new -- it happens with five records created yesterday. And changing the architecture is not going to help because if you need to store >4k then you need to use LOBs. Period. 

Oracle 12 extended maximum length of VARCHAR2 to 32Kb. And there always was LONG.

On 1/31/2019 at 7:47 PM, David Schwartz said:

Apparently Oracle saves CLOBs and BLOBs directly to disk in their own files, not in the DB.

CLOB / BLOB are stored in tablespaces. BFILE are stored in external files.

You need to use sslxxxx PostgreSQL connection parameters:

https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-PARAMKEYWORDS

And put them into FireDAC PGAdvanced connection parameter:

http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Connect_to_PostgreSQL_(FireDAC)#Connection_Definition_Parameters

Instead of last "Size" reference there should be "Size - 1". Fixed.

On 1/5/2019 at 3:10 PM, ihx said:

.... we'll see when the gyus at EMBT get fixed this 😞

@ihx, please, report this issue to https://quality.embarcadero.com

1) This is worth to report, but rather as a feature request. Support for automatic decoding may be done easily using WinHTTP WINHTTP_OPTION_DECOMPRESSION option. And probably already in 10.3 Update 1. As a quick workaround, you can modify System.Net.HttpClient.Win.pas, for example:

function TWinHTTPClient.DoExecuteRequest(const ARequest: THTTPRequest; var AResponse: THTTPResponse;
  const AContentStream: TStream): TWinHTTPClient.TExecutionResult;

begin

.....

  // Enable automatic decoding
  LOptionValue := WINHTTP_DECOMPRESSION_FLAG_GZIP or WINHTTP_DECOMPRESSION_FLAG_DEFLATE or WINHTTP_DECOMPRESSION_FLAG_ALL;
  WinHttpSetOption(LRequest.FWRequest, WINHTTP_OPTION_DECOMPRESSION, @LOptionValue, sizeof(LOptionValue));

....

end;

2) THTTPReqResp was using WinINet API directly. In 10.3 it was completely reworked to enable support of other platforms, including Linux, OSX, etc.

Changing method to code below and setting FDPhysFBDriverLink1.Embedded to True will make it working. Without that the only workaround is to renamed fbclient.dll into fbembed.dll.

procedure TIBLib.LoadFB(const AVendorHome, AVendorLib: String;
  AEmbedded, AThreadSafe: Boolean);
{$IFNDEF FireDAC_IB_STATIC}
const
  C_FBClient: String = {$IFDEF MSWINDOWS} 'fbclient' {$ENDIF}
                       {$IFDEF POSIX} 'libfbclient' {$ENDIF} + C_FD_DLLExt;
  C_FBEmbed:  String = {$IFDEF MSWINDOWS} 'fbembed' {$ENDIF}
                       {$IFDEF POSIX} 'libfbembed' {$ENDIF} + C_FD_DLLExt;
{$ENDIF}
begin
  if AEmbedded then
    LoadBase(AVendorHome, AVendorLib, AThreadSafe {$IFNDEF FireDAC_IB_STATIC}, [C_FBEmbed, C_FBClient] {$ENDIF})
  else
    LoadBase(AVendorHome, AVendorLib, AThreadSafe {$IFNDEF FireDAC_IB_STATIC}, [C_FBClient, C_FBEmbed] {$ENDIF});
  if AEmbedded and (Version >= ivFB030000) then
    FEmbedded := True;
end;