Anders Melander

It depends. If you are sure that your event handlers are thread safe then COINIT_MULTITHREADED is fine. Otherwise change it to COINIT_APARTMENTTHREADED. Well if you code isn't thread safe then anything can happen but I think it's more likely that the missing CoUninitialize is the cause.

I just checked the source: On Windows it's just a wrapper around the Windows SRW lock. https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks

There's no need to post the issues that weren't fixed when we have a list of those that (allegedly) was.

CoInitialize etc. only affects the calling thread. If you access FireDAC from a thread, and you have called CoInitialize on that thread, then any inbound COM will be executed on the main thread (i.e. single threaded apartment a.k.a. apartment threaded). I'm guessing you are only doing outbound COM so the threading model shouldn't matter.

And now demo.exe is running you

https://docs.microsoft.com/en-us/windows/win32/api/objbase/nf-objbase-coinitialize And the documentation for CoInitializeEx states:

Why is that man trying to swallow an invisible shoe?

It's a service application so the COM stuff is presumably done in a thread. The CoInitializeEx/CoUninitialize should be done in the thread. Apart from it being inefficient there's nothing wrong with looping and wrapping the server interaction with local calls to CoInitializeEx/CoUninitialize inside the loop. Outside the loop would be much more efficient of course but it might be a good idea to start again with a fresh, clean COM environment after the server has disconnected the client.

It's probably using CoDisconnectObject

Okay. Let's assume that the problem lies with the client. Apartment threading just means that ingoing COM calls are executed on the main thread. This is like using TThread.Synchronize to ensure that code that isn't thread safe is executed in the context of the main thread. If your code is thread safe or if you are sure that you're not using callbacks (e.g. COM events) then COINIT_MULTITHREADED is probably fine. The missing CoUninitialize will affect the client but assuming that you clear all references to server interfaces on disconnect then I can't see how that would affect the server. So your code logic should go something like this: CoInitializeEx(...); try Server := ConnectToServer; try Server.DoStuffWithServer; finally Server := nil; end; finally CoUninitialize; end;

https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex Anyway, that's on the client and it shouldn't affect the server.

Maybe. Since the OP hasn't really stated what his problem is I can't tell for sure. It sounds like he's asking about adapting Git to his workflow or vice versa, which I think is a topic suitable for SO. It depends on how you phrase your question. Regardless there's a good chance he would be told to ask a proper question if he tried SO - or maybe just downvoted but that's also kinda an answer.

I think you need to post some more code and some more details. Does the OleCheck ever raise an exception? If so how do you handle this exception? Are you sure that you shouldn't be using COINIT_APARTMENTTHREADED instead? Are you sure there's a CoUninitialize for every CoInitializeEx? How does the server disconnect the client? Have you tried debugging the server to determine what it's doing when it "hangs"?

Are you aware what the M in MTBF stands for? And it's not the statisticians that are making these claims we are talking about. It's the companies producing the devices, based on their tests, and it's the people that have the experience to back the claims. And yes, they're "experts". Because they know what they're talking about. Like Wozniak. Unlike Jobs.

I'm doing incremental backup and I rotate media every one or two weeks so it's not that bad. The "other house" is right next to the main building and the cabinet is in my workshop, right next to where I keep the beer, so it's nice to have an excuse to "go file the backup".

What I meant was wear from thermal expansion and contraction. There are lots of other factors to consider but it's kinda pointless to explain in detail when you're up against SDs and Raspberry Pis.

I of course meant that the two should be separate after the backup has been made. Not during. At home I'm doing rotating backups to disk. The disks are stored in a non-fireproof cabinet in another building. I'm betting that both buildings don't burn down (or are towed away by "burglers") at the same time. I live in a thatched house so it's not like I'm fireproof in any way.

What are you on about? There's a difference between a fireproof safe which is primarily a safe and a fireproof safe which is primarily fireproof. Guess which one you should use to protect your backup media against fire? The reason it's "a safe" is that if you're going to build a big steel box then you can just as well put a lock on it and call it a safe. If you are afraid that someone are going to steal your safe then close the door but don't lock it. Jeez.

No. You want your media isolated from anything that can damage it. That includes the backup device. Build a lego robot if you want it automated A small fireproof safe isn't that expensive. 400 EUD will get you started and I'm sure they can be had for a fraction of that second hand.

Stackoverflow.

I have multiple projects that are heavily dependent on DWScript and I like to think I'm a bit of a DWScript expert after having used it for so many years (since 2002). However... It's a bit hard for me to judge if the implementation is "very clean" because the source is close to unreadable to me. The architecture might be solid but I have spent hours trying to solve problems by reading the source and the non-standard code style and the lack of comments in the code means it's futile to try to learn from the source. It has improved since DWS2 but not enough. Another problem is that there's zero documentation and the examples only covers very basic use cases. So expect a steep learning curve. Finally there's no community and it's maintained by a single person who doesn't seem interested in letting anyone else work on it. But apart from all that I can also recommend DWScript. Here's an IDE for DWScript if you need it: https://bitbucket.org/anders_melander/dwscriptstudio

And if everything else fails there's always the NSA to fall back on. https://www.cnet.com/news/guess-what-happened-when-backblaze-tried-using-the-nsa-for-data-backup/ https://o.canada.com/technology/internet/irony-alert-google-labels-nsa-data-centre-backup-service

Sure. If you want reliable backup use a media that has been designed for it. Floppies, writable CDs and DVDs, cheap HDDs, SDDs and SDs aren't reliable. I have TK-50 DLT tapes from the late eighties that can still be read (each tape contains a whopping 94Mb). The tape format is standard and the drive is SCSI so it's no problem finding a way to read them - and the data is still there. Try that with any other storage type after thirty years (stone tablets and punch cards excepted). I think it pretty irresponsible to make a statement like that. You can't guarantee anything like that and I'm pretty sure you will not take financial responsibility when your guarantee turns out to be false. The companies that make these devices doesn't even make such claims. It is known that SDD and SD degrade over time. Their good MTBF is only valid when they are new.

Design-time packages are always 32-bit only since the Delphi IDE is 32-bit. You don't need the package installed to build. You need them installed to have design-time support. E.g. being able to drop SynEdit controls and components on forms, set their properties at design time etc.

Oh, and another reason why this is wrong is that it's better for HDDs to run continuously. It's the power cycles that kills them (thermal wear).