Lars Fosdal

Considering every major ERP vendor is moving to cloud, I would say that the trend is "no". However, these are typically enterprise sized ERP systems. There may be a niche for small shop owner ERPs - but there are already tons of these out there, and even some of those are cloud based. As soon as you exceed a single user, you are in database territory, and when you talk mobile apps, you definitively are in web service country. I would suggest that you really research your intended target audience to see if there is a gap where a desktop app could fill a need. I would also suggest that you narrow down and "modularize" your functionality, because the concepts of ERP systems and their near relatives are REALLY far reaching. You may suddenly find yourself in Tax, CRM, HR & Salary, document management, EDI and WMS territory.

https://www.theregister.com/2025/02/13/hash_table_breakthrough/ adds some further detail on a different paper, "Optimal Bounds for Open Addressing Without Reordering" which is related to the first "Tiny Pointers" paper. And these Python implementations derive from that paper: https://github.com/sternma/optopenhash

Yeah, that was my thoughts as well. Still, it is fascinating to see innovative ideas on old subjects.

And... now in the correct thread... Did you guys read the article on the undergraduate that suggested new improvements to hash tables? Article: https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/ "Tiny Pointers" Paper: https://arxiv.org/abs/2111.12800

Indeed. The change to 12.3 is really complicating existing code, and although I am not against breaking changes for improving quality, it means that you can't really use 12.3 without rewriting parts of the code. Since we never did go for 12.0 ,12.1 or 12.2, I suspect our projects will stay on 11.3, since the product has entered the care and maintenance phase.

That is technically correct but simply changing from string to string[n] in a record as a workaround to the non-nullable type Generics issue, will cause these warnings.

@bravesofts Place a feature request at EMBT's JIRA. Nothing is decided on this board.

Same for me. Several record types where I had to explicitly add a string length, resulting in numerous [dcc32 Warning]: W1057 Implicit string cast from 'ShortString' to 'string'

I agree. Bold-overuse is as bad as shouting in CAPS. It doesn't improve the delivery of the messages, nor the quality of the arguments.

Leading question - so.... what would you check next, Mike?

I see the same in the D12.3 source, but no errors show in the IDE. I copied the source to another unit and compiled it and it doesn't care about semi-colons for external function declarations - not even for those with the delayed keyword. Bug or feature? I don't know, but it certainly is not consistent with the rest of the language.

SQL has always been for the Enterprise tier and up. In 12.3, support for SQL Server 2022 has been added.

TBH, I prefer C# for Azure functions.

Personally, I'd favour work that improves debugging - both in 32- and 64-bit. That said, even an incomplete 64-bit IDE is a step forward, and I am excited to see what can be achieved with the new compiler as it matures.

Is there a limit on usage at that price? Can a DB there be accessed from multiple concurrent instances of your app?

Were the crashes related to missing components?

There is a road-poster. It says "You are here".

There are numerous posts on StackOverflow on this topic, most asking why it is not working as expected 😛 Would it be an alternative to open the excel file in excel and use COM to extract the data from Delphi code?

@A.M. Hoornweg Passing the exception type and callstack info from the server would be useful for making an educated handling in the client, but I don't see why raising an exception in the client would be helpful. The callstack from the server side exception won't be the same as the callstack from an exception raised in the client,. It all depends on the client-side context, of course, so sometimes an exception may be acceptable, but frankly; I prefer to not raise an exception if I can handle a problem flow in a better way.

It isn't worse than your response having result codes that indicate success + data, or failure + type of failure, and your client responding to these the way you want it to. F.x Client -> Server, send me all the details on <some reference> <- Server: dude, that was a bad reference - I almost crashed! Client: Well, server didn't like that, so I better tell the user that the server couldn't find his shit and that the request upset the server.

Why would one declare an empty record?

Firstly, you need to know the nature of the exception. Do you use EurekaLog or MadExcept? If not, you are blind to the actual cause of the exceptions. Do you know what your code is doing when it stops processing requests or why it stops? Once you know what goes wrong, add checks to avoid execution when you have invalid data. It may be useful to have a try/except block to set return values that indicate a failure, instead of exiting by exception, but it is rarely useful to have "catch all" blocks simply to silence exceptions. Secure each piece of code that runs in a thread and uses shared resources with try/finally so that any resource you allocate can be returned to the shared pool, and any locks you grab can be unlocked.

Wrappers for Java/C/C++/C# are not trivial, depending on the complexity of structures and formats. Python might be an alternative - have a look in https://en.delphipraxis.net/forum/39-python4delphi/

https://docwiki.embarcadero.com/RADStudio/Athens/en/Using_the_Google_Play_In-app_Billing_Service

Under which user is the service running? Open "Services", double-click your service, check the "Logon as" tab (W11). Does it allow interacting with the desktop?