Lars Fosdal

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?

I assumed any unmatched on-events would have been silenced. If E is nil - logging will be incomplete in some cases, since I pass the exception object to Eurekalog to capture a callstack for the log. It probably would be quite rare, though.

Not from the top of my head. I would definitively check the monitor to see if there is something enlightening in there?

With TCP/UDP/Serial, JsonRPC, REST, Databases and conversions and partial data transfers possible - you tend to accumulate a number of these.

When dealing with live data, there is no end to what can go wrong - so no - I do not have a small number of top level exception handlers.

That is extremely significant. I have countless numbers of these and I am starting to wonder if they should be rewritten to try // ... except on E: Exception do begin end else raise; end; and then have a general handler for those further out. Or.... just log "An unidentified terrible event happened."

FDQuery.FetchOptions - Does changing Unidirectional to True have any effect? FDQuery.FormatOptions have a TON of settings, including map rules - which may solve encoding issues if the ODBC doesn't provide all the info that FireDAC wants. I.e. you can explicity specify the type of value that the db field should be translated to. From the Delphi Tools menu: FireDAC Explorer can help with experimenting with Format/Fetch options. FireDAC Monitor can also give good insight into the low level goings on when your application is running. Edit: I also wrote this a few years back: .