Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 3 of 3 total |
8708 error which shouldn't happen at all! |
Mon, Oct 30 2006 5:18 AM | Permanent Link |
"Pedrocelli" | I have trawled right through this newsgroup looking at all the messages on 8708
errors, and have not seen one that described this situation generating an 8708 error. I am developing an application with one datamodule in it. The error occurs on the Preferences table, which has just one record in it, and there is only one (count them, one!) TdbisamTable on the datamodule for this table. There is one database component, one local session, and only one user as it's in development. The code does something like this - in a main form, a "wizard" (just another form, really) is called which does a call-back to the main form to create several master-detail sets of records, then opens up a new form to look at and edit one set, then after that closes it goes to a second form to look at and edit the other master-detail sets. The Preferences table is only updated when the data is created with a read to get the next document id, then an edit and change and post when the document is done. By "document" I mean a master-detail set of records, like a purchase order. So it is being updated by the main form. Each of the three forms have their own datasource referring to the one table defined in the datamodule. But a datasource doesn't hold a table cursor, only a dataset, as I understand it. Now if (a) a db transaction is started on entry and committed/rolled back on exit of each subform, it all works fine except it gets messy if the user cancels out of the wizard and finds the data still on file. So to make the unwanted data go away neatly, I changed it to (b) start a transaction at the start of the wizard, before generating all of the master-detail sets, and committed/rolled-back on completion of the wizard depending on how the user exits the wizard. Now, though, I get a @#$%^ 8708 error on the Preferences table on exiting each subform and I can't see why! There is only one user. There is only one thread. There is only one dataset accessing the table. It has no blob fields in it. The changes are made sequentially - each read is followed by an edit and a post. The table does not appear to be corrupt - I don't get it doing other things in the app and that table is referred to everywhere, although I will run a table verify/repair just in case. And the error is only occurring on the Preferences table, which isn't (I don't think anyway) being changed in the subform anyway. Perhaps this error is precluding similar errors on the master or detail tables, I can't tell. Wrapping the record generation routine and the subforms each in a db transaction prevents the error, but causes other issues. Why? Why? Why??? My head hurts ... Pedrocelli |
Mon, Oct 30 2006 8:03 AM | Permanent Link |
"Robert" | "Pedrocelli" <@> wrote in message news:7D737A3E-0D73-4FFA-8498-A26B52E0D91E@news.elevatesoft.com... >I have trawled right through this newsgroup looking at all the messages on >8708 > errors, and have not seen one that described this situation generating an > 8708 > error. > Which version of DBISAM are you using? Robert |
Mon, Oct 30 2006 4:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Pedrocelli,
As Robert asked - what version of DBISAM are you using ? << (b) start a transaction at the start of the wizard, before generating all of the master-detail sets, and committed/rolled-back on completion of the wizard depending on how the user exits the wizard. Now, though, I get a @#$%^ 8708 error on the Preferences table on exiting each subform and I can't see why! >> Could you be more specific about where the error occurs ? Does the debugger indicate that the error is occurring on an Edit call ? (it should) As a refresher, the 8708 error can occur anywhere where a TDBISAMTable or TDBISAMQuery (live result) is viewing a record that has been modified by another user, session, or TDBISAMTable/TDBISAMQuery component, regardless of whether the application is single-user/multi-user or single-threaded/multi-threaded. It is simply an indication to you (or the user) that the record that is accessible via the TDBISAMTable or TDBISAMQuery component has been modified since the record was last cached by the underlying TDataSet component. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |