Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread 8708 error which shouldn't happen at all!
Mon, Oct 30 2006 5:18 AMPermanent 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image