Mark Williams

I understand that, but I am keen to speed up user experience at client end and reduce traffic at server end and doing it by way of a local file does that. I will now demonstrated my ignorance of REST services. I don't understand how it will result in faster loading of the same data and less bandwidth.

Noted. Just working in Postgres at the moment and trying to finish an app. Offered in Postgres initially and intending to offer connectors for other dbs when requested. If at the time of doing so I experience any issues I may then opt for REST server. Yes. It's there for PostGres also. You use the PGAdvanced parameter of the connection which gives you access to Postgre's Database Connection Control Functions. They don't have to be. But with large amounts of data it I find it is much faster to load the data from a local file and refresh it from the server in the background.

I've not really looked into possibility of using REST. If I'm not mistaken I would need the enterprise edition of Delphi rather than the mere professional to implement REST services. Not a deal breaker in itself, but I am not convinced that I need to go down that route (time is a major constraint for me at the moment). FireDAC seems to make it fairly simple to change horses between different databases. Isn't it then a question of ensuring your queries etc are compliant SQL and, if not, adapted as necessary for each database you support?

I'm not sure how to measure how much time it takes to retrieve from the server and how much to locally load. However, I know that loading from a static file is significantly faster than loading from the server so I'm pretty sure the bottleneck lies with the retrieval time. I'll have a look at compression. Haven't used it so far and didn't know FireDac supported it. Although my principal goal is to minimize resources server side. Noted. I will try and do it via temp tables.

It's a system for handling documents in litigation matters. So the number of documents can range from a few hundred to hundreds of thousands. Whilst a case is in its early stages the documents will (depending on the nature of the case) be loaded in large tranches. When it gets closer to its conclusion, you will get much fewer new documents being added to the case. I guess a count of how much new data there is and then decide on whether to use where statement or pass in an array of ids. Not sure, but I will look into it. However, I need a solution that will work for Postgre, Oracle and MS SQL at the very least, so it has to be compatible across the board, although I suppose I could write a different routine for each server if needs be. As for the IN clause, if it is particularly large in relation to the total number of records I could just load the lot via a thread and then dump the static data when I have the new data. If it's not too large relative to the total number of records, but still relatively large for an IN clause I guess I could submit in batches.

Unfortunately, I need to be able to offer a range of databases.

Of course, although an ocx usually has a visual element to it rather than just a library of procedure. I thought it may have a problem with ocx because of the visual element. Always best to check I feel.

It can be a pretty massive table, which can take a long while to load. It obviously loads much quicker from local file (even though encrypted). I am keen to avoid passing unnecessary traffic to the server, hence suggestion of local file and update with only the data necessary. There could be just a handful of records to update. I really don't want to download the lot again just for that. I think this is a sensible way to approach it. I'm just not sure that the way I propose to handle it is the most sensible. But I am keen to avoid full reload of whole table.

Had a quick look. Very interesting. Looks like quite a bit of work to produce a large app and also I think it requires replacement of all visual components with their own. Couldnt't see some fast conversion script for this. Maybe it's as easy as copy and replace of pas and dfm file class names. However, I rely significantly on virtualTreeView for display of db data. I don't think the treeview they provide would be suitable. Could convert to TListView, but I couldn't find that as an option on their components page. I don't use DGGrid's for various reasons, but could always consider that. All the same, worth keeping an eye and it could well be useful for "light" version of desktop apps.

That all sounds very promising. Thanks for the comments. My app is fairly heavy duty and with a huge executable (which seems to be par for the course with Delph nowadays). It needs to access several dlls and an ocx. The ocx is mine and could be (possibly should have been) written as a dll. Are there any issues you know of with dlls? I use theming and would like to retain it, but it's clients who are asking for possibility of cloud app, so they can make the choice of living without it. I can keep in the desktop app version. I was under the impression that the license fee charged by Cybelesoft included the hosting of the app. However, the hosting shouldn't be a problem. Each client would probably set up their own internal and external servers to host it. That leads to another question and that's what sort of degradation in speed have you experienced between desktop and cloud? What is actually involved in redeveloping as a web app? Is it possible in Delphi? I haven't seen anything anywhere dealing with this.

Thanks for the link. It didn't seem to work for me. However, it gave me the idea to change my function to repaint the background of the glyph. Now works and will have to do for now. Function GetTransparentImageList(Owner:TComponent; SourceImages:TImageList; BMPIndex:Integer):TImageList; var bmp:TBitmap; begin bmp:=TBitmap.Create; try if SourceImages.GetBitmap(BMPIndex, bmp) then begin Result:=TImageList.Create(Owner); With Result do begin bmp.Canvas.Brush.Color:=StyleServices.GetSystemColor(clWindow);; bmp.Canvas.FloodFill(0, 0, bmp.canvas.Pixels[0, 0], fsSurface); AddMasked(bmp, clFuchsia); end; end; finally bmp.Free; end; end;

From within an app I save data obtained over the internet from a database to a local file so that when the user needs to reopen it can be loaded locally rather than across the net. Also, the user can save other data they are working on for later restoration. My inclination is to place these file in "C:\ProgramData" (CSIDL_COMMON_APPDATA), but I notice Embarcadero, for example, save new projects off "C:\Users\Public\Public Documents". Foxit also use it. Two questions: What is considered best practice for storing this sort of data? How do you get the "C:\Users\Public\Public Documents"? There doesn't appear to be a constant value to use with SHGetFolderPathA to get it. All I can find is CSIDL_COMMON_DOCUMENTS and that gets "C:\User\Public\Documents", which doesn't exist on my version of Windows10.

That's what I've opted for. Thanks.

I don't actually want them to know where the data is and I also want it to be shared amongst anyone else who has access to the app, but only via my app.

And TMyObject(SL[index]).Something Where SL is a TStrings. If I had a dollar for every time...

Ah yes! Thanks

Damn tricky fellas! I should have realised that! It's the third option. So I will place in Public Documents ShellGetFolderPath(CSIDL_COMMON_DOCUMENTS, Path); path := includeTrailingPathDelimiter(path); stream.saveToFile(path+'stream.txt'); Saves to C:\Users\Public\Public Documents' . So all is good. I don't actually want users to try and open the files directly from the folder. My app just needs to know where they are so it can build a list of them (FindFirst...) and offer them via the app for opening. They could be anywhere as far as the app is concerned, it just needs to know how to find them.

I make that error quite often. I've often wondered why the compiler doesn't pick it up.

Does anyone know a way of getting the above to function in 64 bit or is there an alternative?

I did try that, but still couldn't find it any reference to it. Yes. Sorry. Tired and brain functioning slower than usual snail pace. I have discovered that today. Because the because the compiler didn't recognise the unquoted reference to Shell32 I thought that the functions must have been re-packaged differently for 64 bit somehow (Shell64 or some such) . Anyway simply putting quote marks round Shell32 in my old function code worked fine. Live and learn.

Possibly, however it worked a treat in this case and helped me an identify the problem. Please see my last post. As for the code I have posted it earlier (see a few posts back) and note Fred's comments as to UnCoinitialize.

BTW I meant to mention that you would probably have got a faster reply to this question if you had posted it in the FireDac sub-forum in Databases.

You need a datasource that points to the master dataset. The Detail dataset needs to have its Mastersource property pointing to the dataSource (this step needs to be followed for both of the options specified below). You can then either: use the object inspector for the Detail dataset to define the relationship with the Master table (you need to set IndexFieldNames, MasterFields and as already mentioned MasterSource) or if the Detail dataset is an FDQuery you can define the relationship via a parameterized query entered into the SQL.Text property eg "SELECT [fields] FROM [mytable] WHERE [detail_table_foreign_key] = :[master_table_primary_key So in the latter case, if you had a master table called "employers" with aprimary key called "e_id" and a detail table called "employees" with a foreign key called "employer_id" your Detail query would need to be as follows: SELECT * FROM employees WHERE employer_id = :e_id The parameter is case sensitive. It must match precisely the name of the primary key field in the Master table.

I found the code online some years ago. Hadn't noticed the failure to CoUninitialize. Thanks. I managed to get my old code to compile this evening by enclosing Shell32 in single quotes. I didn't realise that an error message would be generated if ILCreateFromPath returned nil. Thanks also for that suggestion. I can now see why my code was doing nothing. Unfortunately, the reason was rather embarrassing. for test purposes, I had hard coded the file path rather than use a dialog and as a result I was submitting a non-existent file! However, without your suggestion re GetLastError I would never have realised that (at least not for another few years).

Sorry. I mistakenly thought Shell32 was restricted to 32 bit and that I was looking another function. I will know better in future (hopefully). Delphi 10.3 update 1. Latest However see response to your last message.