Leaderboard

If lots of people tell you that they don't fully understand your question, I respectfully suggest that you clarify what you are asking. It's easy for us all to write things that we think are clear but find that others don't fully understand. My guess is that you want to stop your program putting anything onto the Windows clipboard. Exactly how to do that depends very heavily on what controls your program uses.

In a good database, the cost of complicated where statements usually is limited once you have tweaked your indexes. Not sure you can get away from those where statements if the client will be receiving NEW rows once every now and then. Not sure how good Postgre is with temp tables., but in MS SQL you could write your existing id array to a temp table, and do a join query. Probably more efficient than trying to match thousands of IDs in an IN statement.

GExperts installer version based on 3040 revision in attachment. I had to archive the installer to fit in Max total size for attachments: 4.88MB. GXRS10.3_1.3.16_experimental-twm_2020-01-10.zip

Example of a "large" VCL app (120 MB exe, using dll's, DB,...) running on VirtualUI. App is intended for desktop only, but VirtualUI allows to support users on MAC's, Linux... Works just fine, but needs a few more lines of code to handle uploads, downloads, etc. but it's doable. Resource use is heavy, but basically a matter of hardware on the server side. Go to: http://coolselector.danfoss.com/ and launch "Coolselector Online" a bit down the page.

I have just tried some of their live demos. They do not work in my Opera browser but they do work with Edge. So depending on your browser, your mileage may vary.

I have designed and written several systems like that. Some have been for use by the end-user (for those that don't understand SQL or data relationship) and some have been for the internal use of an application (to avoid hard coding queries). My experience is that it never worked like it was supposed to. It might be that my designs was flawed but it's not like I haven't tried everything I could think of. It is a much more complex problem than what your description suggests. I actually know of a company that was run into the ground trying to solve it (well, there were other factors but this was the one that broke their back). The last system I implemented consisted of four major components: A data dictionary. Contains the meta data: Tables, columns, relationships, etc. A graph. Basically a Weighted Undirected Graph using Adjacency List that represents all tables and their relationships. A resolver. Given a start and ending node, finds the cheapest path through the graph using Dijkstra's algorithm. A query builder. Uses the input criteria (where), the output list (select) and the path through the graph (joins) to generates SQL. This works great for simple queries, small datasets or simple databases but once you throw a real world, large and complex database at it falls apart for several reasons. Here's just a few of them: It is not enough to find the shortest/cheapest path through the graph. Given multiple possible paths, the solution should optimally pass through as many of the "where"-tables as possible. It's not obvious what nodes to chose for the start and end node and the choice will affect the result. The criteria often needs to be qualified/scoped or the result will not be what the user expected. For example if the user asks the car database for "car.name" where "country.name=China" expecting a list of Chinese cars they will not understand that they receive a list of European cars assembled in China because the resolver took an unexpected path through the graph. There are many other cases where a choice, that affect the result, has to be made but the user hasn't supplied the information required to do so. In many situation the desired type of join to use cannot be inferred form the cardinality of a relation. The users often don't understand cardinality and most often don't even know where they will need to resolve a ambiguity with additional criteria. The query builder don't know how it should resolve a many-to-many relation or if it should resolve it at all. My recommendation is that you use a traditional query builder instead and concentrate your efforts on the documentation you mentioned.

Whoops! Yeah, I actually discovered that after my comment on the report. I've now updated it. Please refer to my comments on the report: https://quality.embarcadero.com/browse/RSP-18329

I too am a Consolas guy.