Lars Fosdal

Yes - clean machine - clean install - no previous Delphis - and the .dproj files came from a repository also maintained with Delphi 11.1.

Word of the year in Norway: "Krympflasjon" - i.e. "Shrinkflation". A general principle where the price stays the same, but what you get for that price is less. Example: A pack of ham at 150g / $3 becomes a 120g / $3 pack. It is of course the same as inflated prices, but the businesses are trying to hide the fact. Food is more expensive, but not as bad as those US examples. Gas is up, but down from the top this spring. Electricity is ridiculously expensive, thanks to a silly guy with a stupid invasion plan further east. However - on the bright side - we need more IT people! Unfortunately, Delphi is not the most sought-after experience. But still - there are a many jobs available in IT here in Norway.

Even simple solutions can lead to complex problems.

Also - a 32-bit application cannot use more than about 2 GB of memory, regardless of the amount of RAM in the machine. Yes, there is a trick to extend that to about 3 GB - but that is only a temporary reprieve. Another memory saving trick would be to scale images to the appropriate size and quality before storing them. If you have a 12 Megapixel image that never will render bigger than 1024 x 768 - it should be scaled and compressed before storing it.

The format of the data and how they live in the application decides the memory consumption. Think about web content. Huge amounts of graphics and video in a 32-bit browser 32-bit OS, even with as little as 2Gb of memory. How does it do that? Load on demand and using temporary storage outside the browser such as file cache or direct streams. If we load a block of data from a DB - and that data has to be loaded into a stream - and then fed into an editor - we are using that memory at least three times, maybe four - depending on how the control stores the data. Divide and conquer. Instead of one blob - use a separate table to hold individual images. Explore if there are ways to load the image data on demand instead of embedding them in the control.

You have a problem. You apply RegEx to solve the problem. You now have two problems.

I read / comment here whenever I have a few minutes to spare, but I can't commit to answer personal messages for support. I prefer to do the communication here, as other may (or may not) chip in - since that is what a community is for.

I suspect it has to do with how the images are loaded into the TAdvRichEdit. Have you looked at TPictureContainer / THTMLPictureContainer that can be used to supply images to the editor?

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.