Lars Fosdal

The problem is - the more complex a question, the more complex an answer. As long as ChatGPT is mostly right, most of the time - it is high risk that an answer can be a little wrong or a lot wrong. I will not waste time on solutions that might be partially correct or completely wrong, nor will I spend time on researching the problems other people have with shit they got from ChatGPT. When it gets better, we can discuss it again, but I suspect it would be better use of ML to find flaws or room for improvements in our own code. There is learning in the struggle to understand a new topic. Ready made and wrong answers from an "inventive" "AI" are not good for learning.

If there is an automated system that can eval Delphi libs, I'd like to know it!

Even those with a non-restrictive license?

ChatGPT is still ShitGPT, IMO.

@Fr0sT.Brutall Why has been answered in the thread.

So, my project group with 25 applications, built 7.6M lines of code in 3 min 16 secs without a hitch on my Lenovo P16. I was not surprised, having already tested the builds in my VM during the subscriber beta. But - when I ran the applications against certain production systems - I got an error I had never seen before. After numerous fiddlings with breakpoints, I discovered that the hosts that failed all were ip.ad.dr.es\instance instead of hostname\instance. When googling the error message, I eventually found references to Kerberos security failure and spelunking further, I found a suggestion to add the following to the connection string: In Delphi code, that means adding FDConnection.Params.Values['ODBCAdvanced'] := 'TrustServerCertificate=yes'; to your connection initalization code. Studying the release notes after 11.1, the 11.2 release states which is the one I had installed, but perhaps the Kerberos authentication bit was ignored because the older FireDAC code didn't twiddle the right params? Anyways - problem solved - No more The target principal name is incorrect for ip address host names.

Pfft. Now I discovered that it is already documented at https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Connect_to_Microsoft_SQL_Server_(FireDAC) There is just too much doc to plow 🙂

No, it is related to the use of ip address instead of hostname which creates a trust failure, unless the client automatically approves the server side certificate for establishing a secure connection.

My hard-earned advice Refrain from replicating the database structures in the REST API. Think about the tasks you want to execute, and what data that is needed for these tasks. It doesn't matter how they actually are stored in the database, as it is the REST server's job to sort out what goes where and how. It also enables you to swap out the underlying database without changing the API itself. Use JSON data packages. The good thing about these, is that you can have missing or extra fields in both directions, making the API less fragile. If a value is missing and not critical, simply use a default instead. If an unknown value arrives, just ignore it. This moves the versioning to the API levels, instead of purely on the database. Try https://api.swaggerhub.com for building APIs. Swagger files, now known as OpenAPI definitions, are very useful as there are numerous dev tools that can use them to create both server -and client-side code or configuration. Do not expose primary keys in the APIs - if you need an actual unique key, create a GUID field in the database and use that as the unique id. It is way too easy to do serial breach attempts on queries where the PK is just an integer. Use secure connections - i.e. https. Make sure you use proper authentication. OAuth2 with limited time keys. Remember why it is called RESTful and obey the rules

Perfect. I should have seen that, but I only tested it on a single .xsd file and was just waiting for the crash that didn't happen.

Excellent work, @Miguel Moreno! Is there a way to control the number of levels for recursive XSD types?

Voted.

@Jasonjac2 I haven't read Cary's FD books, so I don't know if there has been any amendments? http://www.jensendatasystems.com/aboutcj.html

I give up.

Quick, Good, Cheap - you can only pick two.

CoInit/CoUnInit - Prior to starting DB components, and after the last disconnect I do this because I have zero control over what a DB driver does with regards to COM.

I thought ckForwardOnly was implicit when setting Unidirectional to true. When you look at the Monitor log - are all field types what you expect them to be? Personally, I always use CoInitialize(nil); CoUnInitialize; for projects that use a DB driver. Also when there is only a single main thread.

Then I am afraid that uninstall/reinstall is the next alternative. Unless @eivindbakkestuen has some other idea?

Can you rephrase that question? I don't understand it.

No. PS C:\Users\foslar> '£'|ConvertTo-Json "£"

Such issues needs to be raised directly with EMBT. Noone here can assist in resolving them.

Is there a Nexus db connected component in one of the apps of yours, which is active at design-time, but which db cannot be reached from your PC?

This is indeed weird. Have you called CoInitialize(nil); CoUnInitialize; at start/end of app/threads?

Good point. I forgot about that since we don't use DB controls but feed regular grids from our query data.

I don't see any such limitation mentioned?