Lars Fosdal

In this case - you just may have to. The mechanisms are so completely different from Paradox to SQL, especially for large tables. You could in theory write a wrapper that can emulate locate and SetRange - but that would be a stumbling block.

Back before 2006, I had literally terabytes of data in Paradox tables on client sites. It initially used local tables on the client, the moved to shared tables on a file server, before I wrote a client/server middleware type of access method that got rid of a LOT of sharing/concurrency issues. I was very happy to leave that in the back mirror. If you want to keep the Paradox tables but change the access method - I'd question if it is worth the hassle. If you are going to migrate, why not do it properly?

I'd have a TBytes buffer and a list/array on the side where the parser breaks down the offset, "type" and method for extracting the buffer content in the appropriate form. If you use a circular buffer - it is slightly more complex - but not exceedingly so. The list/array on the side could also be circular.

Another factor for your choice: TBytes - zero based indexes AnsiString/RawByteString - one based indexes So - doing over will be a pain.

o.0 - I have it running on several machines, and haven't seen that trick yet. Auto-upgrade, yes, but not auto uninstall.

How are the strings delimited in the buffer? IMO, if you need to copy the strings out of the buffer to work with them anyways, you might as well future-proof for non-ascii and copy to a regular string with the appropriate routine. That can allow you to sanity check the string in context of format, and handle abnormalities.

What format is the string source? UTF-8? Ansi? How are string buffers measured? Byte/word length? Character length? Zero terminated?

TBytes.

GitHub. We are moving world+dog to the cloud. Current SVN is on-site, and requires maintenance.

The organization wants us to switch from SVN to GitHub, but most of use have very limited experience with git - so it is a learning curve that I expect will yield some hard-earned experiences. However, I think we'd want to go all in, instead of this in-between solution?

First impressions, based solely on the visuals: All sides have the same color, which gives you little to no contrast. You don't have a highlighting color for the contour. Perhaps slightly darker sides would help, and maybe a lighting source to enhance contrasts?

That second one was bad.

I see that the second option in the answer is the same as mine.

I.e. that server does not produce valid Json.

We do use it at work. It is pretty uncomplicated to use, but yeah, a lot of features and settings to be explored to master it fully.

@dummzeuch Have you tried the free Solo version of Continua CI? It is full featured but limited to one task at a time. Beats batch files by a mile.

"Let it crash" is not on my list of stability strategies.

What if you test it on the Form/Frame OnKeyDown and check if the Sender is that Combo? Would you then be able to instruct the Combo to do the "Enter thing"?

No, it can't. Only what you decide should happen, can happen. Only if it was badly written, or there were no measures in place to regulate resource consumption (number of threads, memory, limited resources). On killing threads - often there is a risk to just kill a thread that is doing some sort of processing, particularly if that processing stores or sends data somewhere. Killing it could lead to memory leaks or limited resource leaks as it would be terminated without cleaning up after itself. A watchdog needs to be aware of what it is watching. It is kinda pointless to restart a process that is not processing, if there is nothing to process. But, since we have zero clue to what kind of processing this mystery service will perform, there is little use in speculating on how to handle "anything nasty" that could happen.

Your Json example consists of an array containing a single string that appear to contains the Json you actually want. { "result": ["[{\"email\":\"XXX@gmail.com\",\"regid\":\"12312312312312312313213w\"},{\"email\":\"YYYY@gmail.com\",\"regid\":\"AAAAAAA\"}]"] } That is why you see the \" escape for each double quote in the actual Json. If you removed the outer array and string quotes, you would see this, but that is not valid Json, as there is no left side reference to that array. { [{ "email": "XXX@gmail.com", "regid": "12312312312312312313213w" }, { "email": "YYYY@gmail.com", "regid": "AAAAAAA" }] } For it to be valid, it would need to look like this. { "result": [{ "email": "XXX@gmail.com", "regid": "12312312312312312313213w" }, { "email": "YYYY@gmail.com", "regid": "AAAAAAA" }] } Somewhere in the process, that Json has been badly mangled. Why is there an outer array and string quotes around the Json you want? The question is: did it happen on the server side, or on the client side?

You don't want do direct app to DB operations, but put something like a rest service in between the app and the DB.

What are the pitfalls that can cause the service to stop running? If the service stops hard, Windows can restart it, but if it becomes unresponsive - that is harder to deal with. What if it is partially unresponsive? Is it safe to kill it? I'd prefer to know the risk factors here. Normally, healthy code does not suddenly stop running?

OMG, @Anders Melander - I feel for you! Refactoring is hard with mastodont routines like that.

Here is a very simplistic mechanism we use in production to have an application or service restart itself. No second process. We use it for our services that runs 24/7/365 to do f.x. restarts for upgrades (Rename running .exe, copy new exe to same name, prepare restart and exit service). https://pastebin.com/YCiqiNAq

Perhaps it works well because I am very restrictive with installing plugins?