Lars Fosdal

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?

FireDac is not a database, but Delphi's DB Driver framework. There is no practical size limit in FireDac itself. The limits would be the limits of the underlying database. What is your actual underlying database? A good allround DB is designed to be on disk and to be manipulated on disk and use memory mostly for indexes and caching. Using a billon row DB that fills terabytes of diskspace, does not necessarily imply a performance problem. There are free DBs you can use - even commercially: Postgresql, MariaDB (Open source MySQL), Firebird, etc. Ideally, you would want to limit what you keep in memory, and instead pull in stuff on demand - but that means a redesign of your application. However, if you need/want to load and keep everything in memory, switching from 32-bit to 64-bit will offer a much larger memory space (but then you have to face the sorry state of the 64-bit debugger).

I'd use the blame view in git to get those dates. The problem with adding an explicit date in the todo comments, is that the comment text may change, but the date is not updated.

@David Heffernan - I write about my own preferences, based on my own code, the libraries I use, and the experiences I've had. I am not trying to recommend a "one right way" to write code, since there are so many considerations depending on the context. Which part of "I prefer" do you consider to be a generally invalid point?