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.

Adam


The only thing I can think of is to call FlushBuffers on the table before closing it.

Roy Lambert [Team Elevate]

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

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.

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.

"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.

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]

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

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.

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