Lars Fosdal

Can you exclude the field(s) that holds the big chunk image data from the search view - and instead, when a single search item is focused - load just that field alone on demand?

The point of identity fields is to be able to do table joins without relying on unique keys in your data. You can still have other unique keys - f.x. for books, it could be the ISBN, for warehouse articles it could be the EAN code, for shipping containers it could be SSCC. All of these are supposed to be unique - but they are strings, and hence far more expensive with regards to space and computation. And - at times, those unique IDs might not be available at the time of insertion (example of unique field that allows for multiple rows with field = null). As I mentioned - the point of the identity field is to be able to create relations without involving the actual data. The value will not change for the lifetime of the row(s), even if you later change all the actual data for that record - including other columns that must be unique.

I am not sure if I understand your question?

A common way to deal with unique identities in a database is to use an auto-incremented identity field. SQLite has an autoincrement feature PostgreSQL calls it a Serial MSSQL names the feature Identity, although they also have a synonymous auto-increment feature MySQL and MariaDB call it an Auto_Increment Basically, it is an automatically incremented integer value which uniquely identifies the row, without having any other relation to the data in the row. You use these identity fields as primary keys for efficiently joining tables, and as unique id's for doing updates and deletions. SELECT * FROM t_parent LEFT JOIN t_child ON t_child.parentid = t_parent.id Pitfall - it is not advisable to use these keys as part of a URL - since it allows for fishing for content by variating the id. If you need to expose the row identity as part of a URL, it is better - although more costly with regards to space - to have a second field in the form of a unique GUID.

There can be only one main thread. It doesn't need to do anything else but to spawn n number of other threads, each of which can have their own purpose, and can spawn their own sub-threads.

The struggle is very real. I have a very large collection of screwdrivers and bits of assorted sizes and types.

I sometimes use objects for parameters if they need to live on within subsystem that the called method belongs to, or when the returned object needs to live on. I use records when I need a function to return multiple values that soon will be discarded. I sometimes use methods within the record declaration to simplify the most common parameterizations.

True. I should have said type flexibility.

Screwdriver - what type? Flat, Philips, Pozidriv, Hex, Torq? 😛

If you return a class instance, you have explicit memory management to deal with (remember to dispose of the response), unlike records where it is handled implicitly.

A record can mix types. TArray<Double>, not so much, even if I can stuff integers into a double. It is a risky approach to bet on accessing the correct index of an array, instead of a named value in a record. But - both methods have their use.

Trouble? 😉 I use a record for returning multiple values. Clarity and type safety is of importance to me.

That is interesting code. How is the performance?

You are welcome. So, SQLite wants to load a lot of data unless you filter? Good to know.

Very low seen from Norwegian salary range perspectives as well.

This is essential to catch issues in runtime. Running an executable without it is like making a train travel blindfolded. You might get where you are going, but if something unpleasant happens on the way, you have no idea of what actually happened. EurekaLog or MadExcept are the best known solutions for capturing exceptions and stack traces.

Did you try going 64-bit?

My bad for not reading your example closely enough. The problem is that you are not searching for a substring %G:\Delphi Projects\image32_3.2.2\Examples\Layers101% is a superset that contains values that are NOT in the database. You want to find out if your DB text is contained in your parameter - which is completely different thing. FDQuery1.SQL.add('Select MainDirectory'); FDQuery1.SQL.add('from Files'); FDQuery1.SQL.add('WHERE INSTR(''' + Edit1.Text + ''', MainDirectory) > 0'); The above will return lines where the MainDirectory strings are found as part of the string in Edit1.Text.

The example does not exemplify the problem. (Delphi 11.1)

Did you try it with a ESCAPE '_' clause?

I still think it is the underscore that plays a trick on you? Ref. https://www.sqlitetutorial.net/sqlite-like/ - section "SQLite LIKE with ESCAPE clause"

Could there be some sort of escape handling kicking in? Is it necessary to pre-process the text you send as parameter to ensure it is correctly handled by SQLite?

@limelect You probably should read the SQLite docs in detail. Perhaps there are clues to debugging memory consumption there? Is it a configuration thing?

Leaks come in many forms. It might not be in the Delphi code. https://www.sqlite.org/malloc.html

Can it be a leak in the application? I.e. you use a DB resource, but never release it after use?