Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
Problem with data being 'undone' in DBISam. |
Wed, Jan 7 2009 12:22 AM | Permanent Link |
"Adam H." | Hi,
I've just come across an interesting problem with one of my applications. This problem only occurs when using DBISam in stRemote instead of stLocal. (Client/Server mode). I have a table (empty) at the start of the application. As the application is beginning to run it populatest the table with 147 records. (These are viewable via DBSYS so I know they're there). A few lines down, a condition is checked and if found to be true, "application.terminate" is called to terminate the application then and there. Up until application.terminate the records are viewable in DBSys (even after hitting the refresh button). Once the application has terminated, the records have been removed from DBSys. My first thought was that maybe I had started a transaction somewhere, but DB.Intransation was false, so I knew that to be the case. I have also tried adding in the following lines prior to the application.terminate with no luck: SettingT.close; //My Table mainform.DB.CloseDataSets; //My TDBISamDatabase mainform.DB.close; mainform.DB.Connected := false; mainform.DBS.Close; //MyTDBISamSession application.terminate; This problem ONLY occurs with Client/Server based applications, and not local based ones. Is there something else I need to do to correctly close the database session before terminating an application? DBISam 4.26b1 on Windows Vista 32 / Delphi 2007. Cheers Adam. |
Wed, Jan 7 2009 2:01 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
The only thing I can think of is to call FlushBuffers on the table before closing it. Roy Lambert [Team Elevate] |
Wed, Jan 7 2009 8:48 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Up until application.terminate the records are viewable in DBSys (even after hitting the refresh button). Once the application has terminated, the records have been removed from DBSys. My first thought was that maybe I had started a transaction somewhere, but DB.Intransation was false, so I knew that to be the case. >> You're running in a transaction somewhere or else you're accessing a different database and/or table than you think you are. A client process termination will have no bearing on what the DBISAM Database Server is doing with the data. Of course, I'm assuming that you're creating a table on the server machine, and not a local table, correct ? -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 7 2009 5:07 PM | Permanent Link |
"Adam H." | Hi Roy and Tim,
Thanks for your replies. I've tried adding SettingT.FlushBuffers to my code, but no success. I've also double-checked to make sure that the database isn't in a transaction and it definitely is. (A call made to DB.Commit raises an exception that the database isn't in a transaction). However - I have found this. If I stop the applicaiton right before the applicaiton.terminate and kill the applicaiton manually (CTRL+F2) the records remain. If I allow the applicaiton.terminate code to execute, the records are removed. If I add a record manually to the table (via DBSys) when I start, the table is populated with other records, and when the application.terminate is processed all 'new' records are removed that the application inserted, but my manually added record remains. > You're running in a transaction somewhere or else you're accessing a > different database and/or table than you think you are. I've double checked both these. The table I'm accessing via DBSys is the only one opened. When I put a breakpoint on the application.terminate and stop just before, I can do a refresh in dbsys and see all the records. When I allow the application to continue, the records are removed again after doing another refresh in DBSys. > A client process termination will have no bearing on what the DBISAM > Database Server is doing with the data. Of course, I'm assuming that > you're creating a table on the server machine, and not a local table, > correct ? Neither. The table already exists - I'm just adding records to an existing table on the server machine. (Which is the local machine, but accessing the data via the DBSRVR application). Cheers Adam. |
Wed, Jan 7 2009 5:26 PM | Permanent Link |
"Adam H." | Hi Guys,
I believe I've found a work around.... I have changed the code to this: SettingT.close; //My Table mainform.DB.CloseDataSets; //My TDBISamDatabase mainform.DB.close; mainform.DB.Connected := false; mainform.DB.free; //<<<<<<<<< THIS LINE ADDED************ mainform.DBS.Close; //MyTDBISamSession application.terminate; Apparently forcing the TDBISamdatabase to free itself will stop the records from being undone. Without this line in there the mentioned problem still occurs. This will work for me anyway, as I'm terminating the applicaiton so I have no problems freeing the database component just prior to doing the terminate. Cheers Adam. |
Wed, Jan 7 2009 8:13 PM | Permanent Link |
"Robert" | "Adam H." <ahairsub5@jvxp_removeme.com> wrote in message news:8B6FCFBE-7444-4390-9E08-AE3B35A1C6E6@news.elevatesoft.com... > Hi Guys, > > I believe I've found a work around.... > > I have changed the code to this: > > SettingT.close; //My Table > mainform.DB.CloseDataSets; //My TDBISamDatabase > mainform.DB.close; > mainform.DB.Connected := false; > mainform.DB.free; //<<<<<<<<< THIS LINE ADDED************ > mainform.DBS.Close; //MyTDBISamSession > application.terminate; > > Apparently forcing the TDBISamdatabase to free itself will stop the > records from being undone. Without this line in there the mentioned > problem still occurs. > Please. Be serious. You have some piece of code there that is deleting your records. You better find what it is, or it will come back to give you some other unpleasant surprise. Robert > This will work for me anyway, as I'm terminating the applicaiton so I have > no problems freeing the database component just prior to doing the > terminate. > > Cheers > > Adam. |
Thu, Jan 8 2009 2:02 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
I agree with Robert here. A workround is good since it allows your app to run but you need to find the root cause. I suggested FlushBuffers just in case the data was help in memory by the OS and wasn't being written to disk. Obviously that isn't the case so there must be some code somewhere that's emptying the new records, probably as part of an event. eg I use flags in a number of places to prevent an event being run on form close. Some (I think OnChange events) are run when a table closes and if they refer to components that have already been freed havoc reigns. Roy Lambert [Team Elevate] |
Thu, Jan 8 2009 7:34 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< I've also double-checked to make sure that the database isn't in a transaction and it definitely is. (A call made to DB.Commit raises an exception that the database isn't in a transaction). >> Scratch that anyways. I forgot that you were looking at the records in DBSYS, which means that there is no way that the records are added in a transaction. I'm with Robert on this one - I think you've got some deletion code running that is deleting the records. As I said before, an application termination with a C/S application will have no bearing on what the DBISAM Database Server is doing. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 8 2009 6:13 PM | Permanent Link |
"Adam H." | Hi Guys,
Thanks for your replies again. Please rest easy - I'm not going to leave it how it is at present, but I will be implementing the work around so the applicaiton can be used at present until I find the underlying problem. The wierd thing is that it works fine in local mode, but not in C/S mode. I shall keep looking. Cheers Adam. |
Fri, Jan 9 2009 2:21 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
Don't worry you're not the only one with weird bugs. I have a routine that's stripping html down to what I consider acceptable tags for replying to html emails. Works perfectly in a stand alone test app but as part of the real app its stomping on the memory of other components. Roy Lambert |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |