Hi!

I have a very big problem and I don'y know how to solve it...

My application has some optional modules (DLL Forms) as separate
applications, so I can call a Form in a DLL (modal form) from the main
application.

The DLL form has a DBISAMSession, Database and Tables
The MainForm has the same.

1) I open the DLL Form from the Main app, and edit-post a record
2) I close the DLL Form (back to the Main app) and if I append a new record,
an error occurrs:

   DBISAM Engine Error # 8708 Record has been changed or deleted by another
user, session, or table cursor in the table 'temp'

How is it possible if I close ALL the tables before closing the DLL Form?
All tables are modified, then Posted and FlushBuffered on DLLForm.
Even I have tried to Close the DBISAMSession of the DLL!
Why does the Main App think that the table is "in use"?

If I do a "Table.Refresh" on Main App after closing the DLL Form, now it
works.
Why??!

Sandy,

Sounds like the record in the main table is in an edit state
so when you call the append it tries to save the existing
record. Refresh, I believe, cancels any changes and will
re-read the buffers.

If you are editing a record in the main form and then change
it using the DLL, the buffers in the TDataset in your main
application no longer match the data on the disk because
your DLL changed the data. That error occurs when you try to
save a record but some other process (even your own
application with a different cursor) changed the record
after the TDataset was last read it into its buffer. The way
I avoid this is by doing all my editing in temporary tables
and then posting them to the disk tables in a transaction.

You could probably avoid any problems by making sure all
your changes are posted before you call the DLL and then
refresh the dataset after the call.

HTH,

Sean

Santy Concepción wrote:

> Hi!
>
> I have a very big problem and I don'y know how to solve it...
>
> My application has some optional modules (DLL Forms) as separate
> applications, so I can call a Form in a DLL (modal form) from the main
> application.
>
> The DLL form has a DBISAMSession, Database and Tables
> The MainForm has the same.
>
> 1) I open the DLL Form from the Main app, and edit-post a record
> 2) I close the DLL Form (back to the Main app) and if I append a new record,
> an error occurrs:
>
>     DBISAM Engine Error # 8708 Record has been changed or deleted by another
> user, session, or table cursor in the table 'temp'
>
> How is it possible if I close ALL the tables before closing the DLL Form?
> All tables are modified, then Posted and FlushBuffered on DLLForm.
> Even I have tried to Close the DBISAMSession of the DLL!
> Why does the Main App think that the table is "in use"?
>
> If I do a "Table.Refresh" on Main App after closing the DLL Form, now it
> works.
> Why??!
>
>

HI, Sean...

Ok, refreshing the table after closing the DLL form solves the problem.

Thanks.


"Sean McCall" <NoSpam@nowhere.com> escribió en el mensaje
news:26DD5025-3B3D-4FFB-8472-63BCBA0A9F92@news.elevatesoft.com...
> Sandy,
>
> Sounds like the record in the main table is in an edit state so when you
> call the append it tries to save the existing record. Refresh, I believe,
> cancels any changes and will re-read the buffers.
>
> If you are editing a record in the main form and then change it using the
> DLL, the buffers in the TDataset in your main application no longer match
> the data on the disk because your DLL changed the data. That error occurs
> when you try to save a record but some other process (even your own
> application with a different cursor) changed the record after the TDataset
> was last read it into its buffer. The way I avoid this is by doing all my
> editing in temporary tables and then posting them to the disk tables in a
> transaction.
>
> You could probably avoid any problems by making sure all your changes are
> posted before you call the DLL and then refresh the dataset after the
> call.
>
> HTH,
>
> Sean
>
> Santy Concepción wrote:
>
>> Hi!
>>
>> I have a very big problem and I don'y know how to solve it...
>>
>> My application has some optional modules (DLL Forms) as separate
>> applications, so I can call a Form in a DLL (modal form) from the main
>> application.
>>
>> The DLL form has a DBISAMSession, Database and Tables
>> The MainForm has the same.
>>
>> 1) I open the DLL Form from the Main app, and edit-post a record
>> 2) I close the DLL Form (back to the Main app) and if I append a new
>> record, an error occurrs:
>>
>>     DBISAM Engine Error # 8708 Record has been changed or deleted by
>> another user, session, or table cursor in the table 'temp'
>>
>> How is it possible if I close ALL the tables before closing the DLL Form?
>> All tables are modified, then Posted and FlushBuffered on DLLForm.
>> Even I have tried to Close the DBISAMSession of the DLL!
>> Why does the Main App think that the table is "in use"?
>>
>> If I do a "Table.Refresh" on Main App after closing the DLL Form, now it
>> works.
>> Why??!

Santy,

<< How is it possible if I close ALL the tables before closing the DLL Form?
>>

The issue doesn't have anything to do with what tables are or are not open.

<< All tables are modified, then Posted and FlushBuffered on DLLForm. >>

That's fine, but the error is coming from the main form, not from the DLL
form.

<< Why does the Main App think that the table is "in use"? >>

It doesn't think the table is in use, it is saying that a record that is
trying to be edited or deleted has been modified by the DLL form so that it
no longer matches what the main form is seeing, hence DBISAM is telling the
main form that it needs to refresh to see the new version of the record.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Santy,

<< How is it possible if I close ALL the tables before closing the DLL Form?
Hi Tim,

Probably the wrong place to ask, but wouldn't the DBISAM error message be better if it
also advised the user to refresh their data?
Or another property on the component, to autorefresh on changed records - not perfect but
great for keeping apps simple with respect to how an end user perceives its' operation.

People could change the error message if they purchased a license to the full source
version of DBISAM - but not all did.

Just a thought.

Graham


Its easy to write an 8708 eater. There's a good example in the manual.

Roy Lambert

Graham,

<< Probably the wrong place to ask, but wouldn't the DBISAM error message be
better if it also advised the user to refresh their data? >>

Good point.  These error messages are intended more for the developer, but
it wouldn't hurt.

<< Or another property on the component, to autorefresh on changed records -
not perfect but great for keeping apps simple with respect to how an end
user perceives its' operation. >>

The issue is that this warning occurs during editing and deleting, so it
isn't a good thing necessarily to just auto-refresh and keep going.

--
Tim Young
Elevate Software
www.elevatesoft.com