Dmitry Arefiev

This is because ODBC 17 is unknown version for FireDAC.

For unlimited number of items for "IN" clause, may be possible to use SQL Server Table Valued Parameter. For details see "Object Pascal\Database\FireDAC\Samples\DBMS Specific\MSSQL\TVP" demo. PS: I am not tested that ...

TFDBatchMoveSQLWriter cannot alter table structure, it can only create a new table.

@A.M. Hoornweg, did you checked THttpClient API ? accept gzip encoded data: set THttpClient.AutomaticDecompression to [THTTPCompressionMethod.GZip] accept an invalid/self-signed SSL certificate: set THttpClient.OnValidateServerCertificate to event handler which optionally can analyze Certificate and set Accepted to True / False

@Edson.pol, could you please provide a test application, reproducing the issue. Also, do you have any non default settings in FetchOptions or ResourceOptions ?

Leave it amBlocking.

1) DB admin features - PostgreSQL 2) DB developer features - PostgreSQL / FireBird 3) Encryption, and ... speed - InterBase. On many tests IB outperforms FB, at least. 4) Mobile platforms - InterBase 5) Change Views is unique InterBase feature If to put SQLite into this list, then if you does not need multi-user access, scalability, DB is relatively small, then SQLite is the right way. If something from this list is not true, or may become false in future, then not SQLite. In order of descending preferences - SQLite, IbToGo / Firebird embedded, PostgreSQL

This may be coded in a more short form using 10.3.2. First case: var JsonValue: TJSONValue; Branch: string; begin JsonValue := TJSONObject.ParseJSONValue(st, False, True); try Branch := JsonValue.GetValue<string>('data.conditions[0].temp'); memo1.Lines.add('Parsed temperature '+branch); Branch := JsonValue.GetValue<string>('data.conditions[2].bar_sea_level'); memo1.Lines.add('Parsed barometer '+branch); finally JsonValue.Free; end; end; Second case: var JsonValue: TJSONValue; Branch: string; begin JsonValue := TJSONObject.ParseJSONValue(st, False, True); try Branch := JsonValue.GetValue<string>('iWN5p2qfRFeGKXn1m3iGnDW0Vkl2.PROFILE.BIRTHDAY'); memo1.Lines.Add('Parsed BIRTHDAY ' + Branch); Branch := JsonValue.GetValue<string>('iWN5p2qfRFeGKXn1m3iGnDW0Vkl2.PROFILE.FULL NAME'); memo1.Lines.Add('Parsed FULL NAME ' + Branch); finally JsonValue.Free; end; end; This is most simple code. Although not fastest, but may be enough fast. Depending on the requirements it may be optimized.

No, because they are rather "features", than bugs, introduced from library beginning. "Fixing" them will break backward compatibility.

More to read: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Configuring_Drivers_(FireDAC)

There are two options: 1) Modify your code. In EventAlert use: TThread.Queue(nil, procedure begin Caption := AEventName + ' ' + DateTimeToStr(Now); end); And in FormCreate set: FEvents.Options.Synchronize := False; 2) Modify FireDAC sources. For that in FireDAC.Phys.pas change method: function TFDPhysEventMessage.Perform(AThread: TFDThread): Boolean; begin FMsgThread := AThread as TFDPhysEventThread; if FMsgThread.Active then begin if FMsgThread.FAlerter.GetOptions.Synchronize then TFDThread.Queue(nil, BasePerform) else BasePerform; end; Result := True; end;

BTW, the test suite in above link is 98% successfully passed by 10.3.1 System.JSON. From 7 failing tests, 3-4 may be considered as a "feature" ...

We have two problems: 1) REST, DBX, System.JSON duplicating JSON serialization classes. 2) Non complete docu for (1) classes. We want to keep only System.JSON with options for backward compatibility with REST, DBX. And only to develop System.JSON. When this will happen, then all demos, tests (internal), docu, must be updated to reflect the current RTL state. Now it is not the time for docu work ...

function JsonEncodeString(const AStr: string): string; var LStr: TJSONString; begin LStr := TJSONString.Create(AStr); try Result := LStr.ToJSON; Result := Result.Substring(1, Result.Length - 2); finally LStr.Free; end; end; It expects AStr without double quotes, and returns text without double quotes. You can adjust it to your own needs. There are several options, eg with/without double quotes, encode non-ASCII chars/do not encode, etc. Probably more simple to implement the above according your needs.

In short future this and other IDE performance issues will be resolved ... I hope 🙂