Lars Fosdal

We always run with MARS=Yes. We also follow a different pattern with regards to inserts and updates - using stored procedures to change the contents of the database. Usually the problem is that more than one operation is attempted on the same connection at the same time. Are you certain you are not crossing variables somewhere? In you example code, there is fdcAmman and fdcUpdateAmman ...

Usually a mess we create ourselves 🙂 It may be that the dead thread raising the exception was trying to use an already disposed reference in it's final moments.

I use EL, so I can't really opinionate on MadExcept. It is very rare that it gives me no clue to the callstack for exceptions caused by dangling pointers, but when desperate, I've turned to using a FreeAndNil overload to set the pointers to a recognizable value, $DEAD0001 and so forth, and logging the line where I set the respective ptr values to at least find a hint to the context that is trying to use it. Problems like these can be a pain to find. Another alternative would be to try with regular threads to see if the problem persists - if it doesn't, it might be that you can attribute it to something OTL specific?

Good info, Brian!

Do you .Free or FreeAndNil? Are you using EurekaLog or MadExcept?

Does this trick have any effect? HttpClient.SetRequestHeader('Connection', 'close'); from https://stackoverflow.com/questions/48321245/thttpclient-is-not-closing-connection-in-delphi

You can move to FireDAC while still using DBase. I know, not your goal - but at least you would have made the first step. https://blogs.embarcadero.com/firedac-odbc-for-paradox-and-dbase-tables/

If a REST call is in progress when you terminate - will the code hangup and close the REST related thread(s) ?

Do you stop the tasks and wait for completion of any running task before stopping the application?

Yes but released in try.. finally. I use Critical section and very short ones. Doesn't that mean that only ONE compression can happen at a time - i.e. serializing your use of CompressFile? Edit: Are you reusing the same critical section in multiple locations in the code or on multiple nested levels? That could become a race condition.

No locks or semaphores in CompressFile?

Regular C# .NET Code transpiles to IL code. When you run, the JITer compiles the IL code to native code - but as you say - on every run. But - You can - with limitations - compile C# .NET code to native code - using the AOT approach. From the second link I posted: There are some elements that are still JITed - such as LINQ expressions - and there is a limit to which libs and platforms that supports AOT - but it keeps expanding from one .NET version to the next.

It is slightly more complex than that... https://learn.microsoft.com/en-us/windows/uwp/dotnet-native/ https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows

FreePascal's Generics support is pitiful. It is impossible to move my Delphi code to FPC.

I haven't tested it, but it certainly appears so.

Known issue: https://quality.embarcadero.com/browse/RSP-15908

Another interesting tool set: https://platform.uno/blog/the-rise-of-c-markup-for-cross-platform-development/

Something that is often overlooked is to limit the redraw frequency. If you redraw the display on every update and there are many updates per second, you may save a lot of time on triggering the invalidate at a capped rate, i.e. not do a full redraw every time, but update once every fixed time interval. Unless you are doing video processing - a redraw at maximum twice per second should be more than sufficient?

My interpretation: This is (string which need to (remove) -> This is This is (string) which (string) need to (remove) -> This is which need to

According to some googling, there appears to be methods of converting a .cer file to a .pfx file.

Staying up-to-date, with the latest stable versions of your libraries, is usually a good idea! If you have proper unit and integration tests, keeping current should be low risk.

@corneliusdavid Perhaps for solo developers, but for a corporate team I would struggle if I was to defend it as a choice.

Who would select to use a closed source backend that doesn't scale, when there are multiple options - of which several have a free tier?

VS Code + C# Dev Kit + .NET MAUI extension for C# Dev Kit is pretty cool. .NET cross platform GUI development on Windows, Mac & Linux. Your Operating System Supported Target DEBUG Platforms Windows Windows, Android macOS Android, iOS, macOS Linux Android You can argue that this is not an editor capability - but well, it is a pretty nifty editor that allows pretty nifty integrations. See also