Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
Creating DBISAMEngine closes tables |
Sat, Dec 1 2007 5:22 PM | Permanent Link |
Norman L. Kleinberg | 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. |
Sat, Dec 1 2007 6:14 PM | Permanent Link |
Norman L. Kleinberg | 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. |
Sat, Dec 1 2007 9:04 PM | Permanent Link |
Eryk Bottomley | 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 |
Sun, Dec 2 2007 10:43 AM | Permanent Link |
Norman L. Kleinberg | 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 |
This web page was last updated on Wednesday, April 17, 2024 at 10:35 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |