There is a lot of information, but it is not easy to truly withstand the 7X24 operation. To put it bluntly, your program is not robust enough.
The data processing is the databaseConnection → Query → Pull data → Generate results → Release connection → Return data. But look at the following:
✅ FDConnection1 It's this TUsegear Members of the class，Depend on DataSnap manage，Each request creates a new instance（Because you used it LifeCycle = 'Invocation'）。
🎯 So the question is: you are using "requesting one object at a time". In theory, FDConnection1 is also new, why may there be problems?
Let’s analyze the essence of this problem very rigorously. Here are some summary and explanations of several possible situations:
✅ Theoretical Model (what you imagine)
Project Your idea (basically correct)
Create a new TUsegear instance per request
FDConnection1 is an object field so each time it is a new connection object
It is safe to use FDConnection1 ❗It seems to be
❗The nature of the problem: Although FDConnection1 is "one new object at a time", the connection behavior of FireDAC involves "connection pooling" or "asynchronous operations", which you may still be processing after the request returns.
🔍 Key point 1: (Result, Query); references the internal structure of Query
Even if you create a new FDConnection1;
You still release Query and FDConnection1 in finally;
But Result still references these structures!
🚨 So as long as the request is still transmitting the Result back to the client and releasing the connection at this time, it may generate:
Access violation at address ... Read of address FFFFFFCD
🔍 Key Point 2: Even if it is "Invocation", the order of object destruction may not be as strict as you think
The FDConnection1 you created is a component field (rather than a local variable derived from Create/Free);
Its release timing is determined by →;
If you are not released specifically in Destroy, the system default behavior may be earlier than the end of the response
🔍 Key point 3: FireDAC will have a background asynchronous release (such as monitors and transaction recovery)
Even if you release Query, FireDAC has a short life cycle in the background (such as a thread is still cleaning up data);
If you close the connection at this time, you may break it;
Accessing the freed memory will naturally crash.
✅ The best solution（You're already doing it）：
| action | Is it necessary | reason | |
| Use local connections within the method | ✅ Highly recommended | Completely isolate the connection life cycle per call | |
No fields are usedFDConnection1
|
✅ | Even component fields may cause conflicts due to unknown life cycles | |
All dataFetchAllRelease Query |
|
Otherwise JSONResult holds a released reference | |
The final release order is strict:Query → Result
|
✅ | Avoid references to pending resources |
🎯 Conclusion summary
Even if you set up Invocation, the problem you are facing:
✅ It is not essentially "whether the connection object is shared",
❗ Instead, "the life cycle of the connection and the decoupling of the data reference are not handled cleanly."
So you are currentlyComponent fields are no longer usedFDConnection1, but every time the method inside(...)and fully controlled release, completely solved this problem.
✅ You have done very well, and the current architecture is:
REST method each time: independent connection → query → pull data → generate result → release connection → return data
🔒 Safe, robust, worry-free threading!