OK. I KNOW what must be happening but I can't figure it out.

I'm using DBISAM 4.25 Build 7 in a BDS2006 (Delphi) app that has been undergoing beta
testing on a LAN for a month now. I have DBISAMEngine, DBISAMSession and DBISAMDatabase
components on the Main form. The app first creates some non-visual global units, then the
Main form is called. One of the units that is created before the Main Form (via an
initialization clause) creates a DBISAMTable and opens it, then exits (it's used as a
counter table to assign Sysids, so I'll call this table "counter"). Since the table is
created BEFORE the engine or session components I leave the table's session blank (for
Default) and set the Database to a directory path.

Everything was working fine (or as fine as a program undergoing beta testing can go); ALL
OF A SUDDEN (isn't it always the case?) I find that the counter table is closing AS SOON
AS THE DBISAMEngine is instantiated. I've traced the source, set breakpoints, etc. and the
close occurs just as the Application.CreateForm is called for the Main form (before
anything executes in FormCreate). If I remove the Engine the table doesn't close. There
actually is a second unit that similarly creates a table which is closed before exiting so
just for kicks I left it open and found that this second table as well is closed as soon
as the Engine is created.

Of course this isn't all of a sudden (I had been fiddling with using a remote server so
some of the settings on the Engine and session were changed) but I had changed them back:
the Engine is set to etClient and the Session to stLocal. I also deleted and readded the
components. Does anyone have any idea what in the creation of the DBISAMEngine could be
causing open tables to close? One possibility that crossed my mind is the issue of not
being able to have two engines (e.g. you set the engine to server and then try to connect
remotely with the Session component, or something like that); however, as I said, the
Engine is set to client and the session to local and everything was working fine before.

Of course it's a stupid setting. I just don't know which one.

Thanks for any pointers, ideas or commiseration.


Norman K.

Well, I THINK I figured it out but I STILL don't know why it has to be this way.

If I set the DBISAMEngine.Active property to True AT DESIGN TIME and leave it that way
then my global
tables don't get closed.

Go figure.


=NLK=

Norman L. Kleinberg <nlk11021@yahoo.com> wrote:

OK. I KNOW what must be happening but I can't figure it out.

I'm using DBISAM 4.25 Build 7 in a BDS2006 (Delphi) app that has been undergoing beta
testing on a LAN for a month now. I have DBISAMEngine, DBISAMSession and DBISAMDatabase
components on the Main form. The app first creates some non-visual global units, then the
Main form is called. One of the units that is created before the Main Form (via an
initialization clause) creates a DBISAMTable and opens it, then exits (it's used as a
counter table to assign Sysids, so I'll call this table "counter"). Since the table is
created BEFORE the engine or session components I leave the table's session blank (for
Default) and set the Database to a directory path.

Everything was working fine (or as fine as a program undergoing beta testing can go); ALL
OF A SUDDEN (isn't it always the case?) I find that the counter table is closing AS SOON
AS THE DBISAMEngine is instantiated. I've traced the source, set breakpoints, etc. and the
close occurs just as the Application.CreateForm is called for the Main form (before
anything executes in FormCreate). If I remove the Engine the table doesn't close. There
actually is a second unit that similarly creates a table which is closed before exiting so
just for kicks I left it open and found that this second table as well is closed as soon
as the Engine is created.

Of course this isn't all of a sudden (I had been fiddling with using a remote server so
some of the settings on the Engine and session were changed) but I had changed them back:
the Engine is set to etClient and the Session to stLocal. I also deleted and readded the
components. Does anyone have any idea what in the creation of the DBISAMEngine could be
causing open tables to close? One possibility that crossed my mind is the issue of not
being able to have two engines (e.g. you set the engine to server and then try to connect
remotely with the Session component, or something like that); however, as I said, the
Engine is set to client and the session to local and everything was working fine before.

Of course it's a stupid setting. I just don't know which one.

Thanks for any pointers, ideas or commiseration.


Norman K.

Norman,

The engine component is a singleton - there can only be one in the
process address space. The design time visual representation is merely a
proxy that maps to the exact same object that is represented by the
global "Engine" variable (the wrapper exists to simplify the creation of
engine level event handlers).

Anyway, what is happening is this: the "counter" table object you
mentioned implicitly causes the Engine object to be created (also the
default session, but that is incidental here) and activating that table
object implicitly sets Engine.Active to "True". You then load the
form/datamodule hosting the TDBISAMEngine proxy component and it has its
Active property set to "False" in the DFM ...ergo Engine.Active gets set
to "False" and that implicitly closes all sessions, databases, tables
and queries in the application. If you are going to use a TDBISAMEngine
design time component then ensure it is always instantiated before any
other data access is attempted.

Eryk

Eryk:

Thanks. It makes me feel better to know what's going on (also, of course, so I don't make
that mistake again). The key was recognizing that creating/opening a table IMPLICITLY
creates an Engine component if one doesn't already exist.


Norman

Eryk Bottomley <no@way.com> wrote:

Norman,

The engine component is a singleton - there can only be one in the
process address space. The design time visual representation is merely a
proxy that maps to the exact same object that is represented by the
global "Engine" variable (the wrapper exists to simplify the creation of
engine level event handlers).

Anyway, what is happening is this: the "counter" table object you
mentioned implicitly causes the Engine object to be created (also the
default session, but that is incidental here) and activating that table
object implicitly sets Engine.Active to "True". You then load the
form/datamodule hosting the TDBISAMEngine proxy component and it has its
Active property set to "False" in the DFM ...ergo Engine.Active gets set
to "False" and that implicitly closes all sessions, databases, tables
and queries in the application. If you are going to use a TDBISAMEngine
design time component then ensure it is always instantiated before any
other data access is attempted.

Eryk