Hi. All of the following to relates to client server only, 2.31 Build 7, Win 10, Rio, 64 bit.

I am creating , in order, a TEDBEngine, TEDBSession, TEDBDatabase, and TEDBScript objects to execute a reverse-engineered database objects script for deployment purposes. I am setting the ConfigPath(s), and SessionName, and Database properties prior to running the script.

All is well, the script executes without error, until I go to Close and Free the objects, particularly the Session, where I get an A/V in a TCollection object when disposing. All the other objects free without problem.

I close all of EDB objects prior to Freeing them, which may be redundant...

I am wondering what the proper order was to free these objects. I have tried reversing the above creation order and other sequences, but get the same A/V for the Session.

Anyone else have this happen? Thanks.

Carl


First thing is why, if you're using client/server, are you creating an instance of the engine. The engine is already there in the server.

Second , as far as I know, the right order to close and free the components would be

TEDBScript
TEDBDatabase
TTEDBSession
TEDBEngine

In general, apart from threads I've found it better to let Delphi / ElevateDB take care of these things for me. Where I've had problems in the past they've been UI and event related.

If the problem persists I'd suggest a demo program sent to Tim.

Roy Lambert

On 8/23/2019 6:16 PM, Carl wrote:
> I am creating , in order, a TEDBEngine, TEDBSession, TEDBDatabase, and TEDBScript objects to execute a reverse-engineered database objects script for deployment purposes. I am setting the ConfigPath(s), and SessionName, and Database properties prior to running the script.

As Roy you do need an engine - it's a singleton and created for you anyways.

How exactly are you creating these in code ?

More specifically are you supplying an owner and if yes then what ?


> I am wondering what the proper order was to free these objects. I have tried reversing the above creation order and other sequences, but get the same A/V for the Session.

In general this should work just fine but seeing snippets of your create
and free code would help.


Raul

On 8/24/2019 1:43 PM, Raul wrote:
>
> As Roy you do need an engine - it's a singleton and created for you
> anyways.
>

a typo here. Meant "As per Roy you do NOT need an engine - it's a
singleton and created for you anyways."

Raul

Roy Lambert wrote:

Carl


First thing is why, if you're using client/server, are you creating an instance of the engine. The engine is already there in the server.

Second , as far as I know, the right order to close and free the components would be

TEDBScript
TEDBDatabase
TTEDBSession
TEDBEngine

In general, apart from threads I've found it better to let Delphi / ElevateDB take care of these things for me. Where I've had problems in the past they've been UI and event related.

If the problem persists I'd suggest a demo program sent to Tim.

Roy Lambert

I changed from creating the EDB objects to just setting up the properties for components dropped on the DM form, thinking it as an create/destroy issue. I still got the A/V error at form Destroy. I have a "release" Session EncryptionPassword property string that is itself stored as encrypted at about 155 hex chars (instead of elevatesoft). I discovered I did not decrypt it to its 32 char length, before setting the EncryptionPassword property. After I fixed it, A/V problem went away.

The reason for the creation method was because a process only runs intermittently to update a secure db. At setup time those encrypted property values are retrieved from from storage, decrypted and applied to the created objects for the process to execute. The problem was never with the object creation and destruction, but the EncryptionPassword value.Once the process has completed, the objects are freed, exposed information like passwords, user names, config path, database, etc. disappear from memory.

The secure db update process will possibly be triggered by a request to a separate REST server and runs independently in background as a service. I am going to use this for cross platform systems.

You are right about the Engine being redundant, but I thought I may have multiple sessions. It may be redundant after all...

Thanks for your quick help. Carl.

Carl


I can't quite get my antique brain around just what you're trying to achive but it looks as though its to complex. In reality it may be very simple.

However, if you are running stuff as a separate background service you will almost certainly need an instance of the engine.


Roy Lambert