Wloochacz

OK, great, but... In this kind of application, fetching all data from the server and all BLOBs is definitely not a good solution... When I write a query, I don't always want to fetch all the data from the server - the first 100 records are enough for me (sure, you can move such a constant to the application configuration), and the rest on demand. Therefore, it might be better to set up FDQuery this way: Result.FetchOptions.Mode := fmOnDemand; Result.FetchOptions.Items :=[]; Result.FetchOptions.Cache :=[]; Besides, if I write such a query and I get an "out of memory" error message I really won't know what went wrong? Where did it run out of memory? On the server? In the application? If in the application, why? Oh well, and most importantly overall - if you always fetch all the data, the query execution time will be long. Or at least it will look like that, but in fact the execution of the query is say 0.1 sec and retrieving all the data is 10 sec.

For your "ugly" database, such code will be the simplest and error-free: aObject.IntValue := StrToIntDef( Fieldbyname('IntegerField').AsString, 0);

I'm sorry, do you know this project? https://github.com/grijjy/MvvmStarterKit It is not pure MVC, but MVVM Here full approval, DMVC (https://github.com/danieleteti/delphimvcframework) is not a project for VCL/FMX applications. And yes and no. Please note that FMX is also not TDataSource oriented, it does not have DBAware controls known from VCL (e.g. TDBEdit) and instead LiveBinding mechanism is used. And in case of MVVM it can work very similarly. In my opinion, RAD is no one's friend and this friendship turns into hatred when the project is bigger and bigger... And it gets older and older, and it needs to be developed. After all, for decades we have been convinced that RAD is great! For everything! Just, it's bullshit.

Hello Jaca! :) There is no simple solution for that. However, I would suggest basing your own solution on the CopyDataSet code. Note that if you specify the coStructure parameter in the options of CopyDataSet method, you will get what you want. Almost ;-)

In general, this is true, especially in SQL executed on the server side, such as stored procedures, triggers, etc. And there, it's better to write like this: select A.* from foo1 A inner join foo2 B on (A.ID = B.ParentID) instead of this: select A.* from foo1 A where A.ID in (select B.ParentID from foo2 B) Although the result will be identical. However, in some cases it is simply convenient. For example, in my application I pass an array of PrimaryKey values to ReportManager so that he can ask the server for the data he has selected on the list. It works like this: And where in SQL looks like this: where TD.IdDevice in (10,12,16,23) Simply clever :P

In e.g Firebird database, yes. In MS SQL it does not matter.

Indeed, but OP work with SQL Server. And this database has no such limits

Use the macro! 😉 fQ.SQL.Text := 'SELECT * FROM tTableName WHERE Status IN (!InValues) ORDER BY EventDate'; fQ.MacroByName('InValues').AsRaw := '''S'', ''R'''; fQ.Open;