I'm working on a new application and decided I'd use some data from an existing application to test a table. I temporarily modified the existing application to do a navigational population of the data in the new table. To to this I created a session, database & table on the fly. That worked nicely .... until I tried to open the new applications table in EDBManager and I got an engine signature mismatch.

The in-progress application is still using the default signature whereas the existing one uses a custom signature.

I'm not sure now if I set the local engine signature for the session I created to the default (I know I did for password, user id), but its the default and it should have been applied anyway (shouldn't it)

What is baffling me is how my existing application was able to open the table for the new application in the first place, and also why it applied the existing applications signature to the new applications table.




Roy Lambert

Roy,

<< I'm working on a new application and decided I'd use some data from an existing application to test a table. I temporarily modified the existing application to do a navigational population of the data in the new table. To to this I created a session, database & table on the fly. That worked nicely .... until I tried to open the new applications table in EDBManager and I got an engine signature mismatch.

The in-progress application is still using the default signature whereas the existing one uses a custom signature.

I'm not sure now if I set the local engine signature for the session I created to the default (I know I did for password, user id), but its the default and it should have been applied anyway (shouldn't it)

What is baffling me is how my existing application was able to open the table for the new application in the first place, and also why it applied the existing applications signature to the new applications table. >>

The TEDBEngine component is a singleton instance and is kept in-memory in the Delphi/C++Builder IDE, so if you opened any sessions/databases/tables/queries, etc. in the IDE while the previously-used TEDBEngine component was still active (you didn't place a new TEDBEngine on any forms/data modules in your *new* application in the IDE), then any files created due to the open would have been created using the *existing* TEDBEngine property settings.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< I'm working on a new application and decided I'd use some data from an existing application to test a table. I temporarily modified the existing application to do a navigational population of the data in the new table. To to this I created a session, database & table on the fly. That worked nicely .... until I tried to open the new applications table in EDBManager and I got an engine signature mismatch.
>
>The in-progress application is still using the default signature whereas the existing one uses a custom signature.
>
>I'm not sure now if I set the local engine signature for the session I created to the default (I know I did for password, user id), but its the default and it should have been applied anyway (shouldn't it)
>
>What is baffling me is how my existing application was able to open the table for the new application in the first place, and also why it applied the existing applications signature to the new applications table. >>
>
>The TEDBEngine component is a singleton instance and is kept in-memory in the Delphi/C++Builder IDE, so if you opened any sessions/databases/tables/queries, etc. in the IDE while the previously-used TEDBEngine component was still active (you didn't place a new TEDBEngine on any forms/data modules in your *new* application in the IDE), then any files created due to the open would have been created using the *existing* TEDBEngine property settings.

Either I'm not understanding correctly (common) or I haven't explained properly (also common).

Application A - engine signature A

Application B- engine signature B

Table ContactsB created in EDBManager under session B - can open in ApplicationB - had two records in it

Modded ApplicationA - created a session, database & table - pointed session at B, database at B tables at sessionB, databaseB, ContactsB

Transfered some data from ContactsA to ContactsB so I had a reasonable sized test set of data

All good and working so far

Went to open ContactsB in EDBManager and received the signature mismatch error.

I didn't create a table in ApplicationA just opened it.

Roy

Roy,

<< Either I'm not understanding correctly (common) or I haven't explained properly (also common).

Application A - engine signature A

Application B- engine signature B

Table ContactsB created in EDBManager under session B - can open in ApplicationB - had two records in it

Modded ApplicationA - created a session, database & table - pointed session at B, database at B tables at sessionB, databaseB, ContactsB

Transfered some data from ContactsA to ContactsB so I had a reasonable sized test set of data

All good and working so far

Went to open ContactsB in EDBManager and received the signature mismatch error.

I didn't create a table in ApplicationA just opened it. >>

There's just too much missing information here to reliably try to reconstruct what happened.  In fact, I can't even come up with a coherent scenario to describe what happened.

The best I can do is list the main points that affect how the custom signature is used:

1) Configuration files, database catalogs, and table files won't actually be created on disk until you open them.  Thus, just using a custom signature in an application is no guarantee that the application will be the determining factor in how the signature is applied to these on-disk files.  Simply opening the same in the EDB Manager in-between setting the custom signature and running the application could result in the engine signature used in the EDB Manager session being applied to the on-disk files instead of the custom signature.

2) The issue of the TEDBEngine singleton instance already mentioned.  Are you using the TEDBEngine component in your applications, or are you using (local) session-specific engine settings ?

Tim Young
Elevate Software
www.elevatesoft.com

Tim


>There's just too much missing information here to reliably try to reconstruct what happened. In fact, I can't even come up with a coherent scenario to describe what happened.

I agree - I did it and I can't come up with anything coherant

>The best I can do is list the main points that affect how the custom signature is used:
>
>1) Configuration files, database catalogs, and table files won't actually be created on disk until you open them. Thus, just using a custom signature in an application is no guarantee that the application will be the determining factor in how the signature is applied to these on-disk files. Simply opening the same in the EDB Manager in-between setting the custom signature and running the application could result in the engine signature used in the EDB Manager session being applied to the on-disk files instead of the custom signature.

I'm going to add it to my long and growing list of "bloody computers"


>2) The issue of the TEDBEngine singleton instance already mentioned. Are you using the TEDBEngine component in your applications, or are you using (local) session-specific engine settings ?

I always drop an engine component on a datamodule and set it to use session settings

If there isn't an easy answer I would recommend you don't waste any more time on it.

Roy