I'm using the TDBISAMDatabase object, with a query object, and based on what the help says, when the query object encounters an exception, you should call rollback on the db object, but
when I do this, I get an error that tells me that the database has no active transactions. I know that it does (as I understand things), because I set up a situation where I don't commit until
let's say the 5th ExecSQL, but I make the SQL.Text invalid on the 3rd try. So, at the time of exception, the commit hasn't been called yet.

Something else, is that when I leave the application up and running, but I .Close and .Free the database object, when it hits the .StartTransaction of the db object on the second time, I get
an error that tells me that the "databasename" still has an active transaction.

I thought the .Rollback would take care of the issue with the transaction staying open, but since that throws an exception (no open transactions), it doesn't appear to be releasing that. I
encountered a similiar situation, and called DB.Session.Close, and that killed the transaction, but I don't really want to do that with this situation because there are so many other
tables/queries that might get closed that I don't know about.

Why does the .Rollback give me an error stating that I have no active transactions? Am I misunderstanding this Rollback thing?
And why, even after closing the db and freeing that object, is it giving me an error about the "dbname" still having an active transaction?

Thanks

thad <thollingsworth@paychex.com> wrote in
news:B8EE43B2-3F53-4E9C-983E-0978BD801F41@news.elevatesoft.com:

> I'm using the TDBISAMDatabase object, with a query object, and based
> on what the help says, when the query object encounters an exception,
> you should call rollback on the db object, but when I do this, I get
> an error that tells me that the database has no active transactions.

Just a thought - is your DB.SessionName identical to the Query.SessionName?

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)

>Just a thought - is your DB.SessionName identical to the Query.SessionName?


I'm not actually setting that property for those two objects. So, whatever it names it for both of them on its own is what it is. Should I name the DB.Session something, and leave the
query.session alone?

All I'm doing is setting the DB.Directory and setting the Query.DatabaseName to the DB.DatabaseName.

thad <thollingsworth@paychex.com> wrote:

>Just a thought - is your DB.SessionName identical to the Query.SessionName?


>I'm not actually setting that property for those two objects. So, whatever it names it for both of them on its own is what it is. Should I name the DB.Session something, and leave the
>query.session alone?

>All I'm doing is setting the DB.Directory and setting the Query.DatabaseName to the DB.DatabaseName.

I have messed up code. I don't think that the .Rollback is giving me an error about the transaction. I have a commit in the top part of the code that's giving me that. I thinnk I'm ok. Sorry
about that.

I have ...


So it was just on the point of commit and after the exception, it came back around in the loop and his the .commit, and that's when it threw the exception.
sorry to waste your time, thanks for the reply though. the whole thing about the exception on the .StartTransaction throwing an error about still has an active transaction must be the code
too.


if time to commit then (if count mod imax = 0, etc)
 .Commit

try
 Query.ExecSQL;
except
 DB.RollBack
end;

thad <thollingsworth@paychex.com> wrote:

thad <thollingsworth@paychex.com> wrote:

>Just a thought - is your DB.SessionName identical to the Query.SessionName?


>I'm not actually setting that property for those two objects. So, whatever it names it for both of them on its own is what it is. Should I name the DB.Session something, and leave the
>query.session alone?

Here's what's going on with all of this. I .Commit at let's say 100, but on ExecSQL exception, I don't want to wast all the previous sql statements (UPDATEs). But, I also don't want the
application to throw an error when it comes back around to the .StartTransaction again. Which is something that's happening. Right now I've got it set up to do a .Commit on the Exception
and that works all right. My data gets posted even the ones in transaction before the exception, and when the .StartTransaction gets called again on the second pass, it doesn't give
a "transaction already open" error.

But I'm a little worried because that's not how the help describes the whole exception, transaction, capture, rollback thing. Have you done any code to work with recovery and rollbacks etc,w
ith the TDBISAMDatabase/Query objects?

Thad,

<< But I'm a little worried because that's not how the help describes the
whole exception, transaction, capture, rollback thing. Have you done any
code to work with recovery and rollbacks etc,with the TDBISAMDatabase/Query
objects? >>

You can get away with a COMMIT in an except block instead of a ROLLBACK when
it comes to executing an UPDATE statement that is part of a series of UPDATE
statements.  I assume that the UPDATE statements are not order-dependent ?

--
Tim Young
Elevate Software
www.elevatesoft.com

thad <thollingsworth@paychex.com> wrote in
news:2287358E-0BE4-470A-8C7A-F4EFC856F22D@news.elevatesoft.com:

>
>>Just a thought - is your DB.SessionName identical to the
>>Query.SessionName?
>
>
>>I'm not actually setting that property for those two objects. So,
>>whatever it names it for both of them on its own is what it is. Should
>>I name the DB.Session something, and leave the query.session alone?
>
No. I just felt that one possible explanation of the DB not knowing you
started a transaction might be that the Query was on a different session,
but on reflection that's not the way things happen - you start, commit or
rollback with the DB, not with the Query.

> Here's what's going on with all of this. I .Commit at let's say 100,
> but on ExecSQL exception, I don't want to wast all the previous sql
> statements (UPDATEs). But, I also don't want the application to throw
> an error when it comes back around to the .StartTransaction again.
> Which is something that's happening. Right now I've got it set up to
> do a .Commit on the Exception and that works all right. My data gets
> posted even the ones in transaction before the exception, and when the
> .StartTransaction gets called again on the second pass, it doesn't
> give a "transaction already open" error.

I'm surprised that anything gets posted, but I suppose it's
understandable if the DB didn't know it was supposed to be in a
transaction...

>
> But I'm a little worried because that's not how the help describes the
> whole exception, transaction, capture, rollback thing. Have you done
> any code to work with recovery and rollbacks etc,w ith the
> TDBISAMDatabase/Query objects?
>

One example of how I use it:
----------------------------8<------------------------
 DataModule1.CJRentalDB.StartTransaction(nil);
 try
   DataModule1.CJRentalDB.Execute('UPDATE Clients SET cliPaymentText =
''' +
     aText + ''' WHERE cliNum = ' + grdMaster.cells[FieldCol('cliNum'),
aRow]);

     // link all payments to clients if possible
   DataModule1.ExecuteSQL(ExtractFilePath(ParamStr(0)) +
     'SQL\UpdateBankStatement.sql');
   DataModule1.ExecuteSQL(ExtractFilePath(ParamStr(0)) +
     'SQL\InsertEachPaymentIntoTable.sql');
   DataModule1.CJRentalDB.Commit;
 except
   DataModule1.CJRentalDB.Rollback;
 end;
------------------------------8<----------------------
I don't actually use a DBISAMQuery, but the rest is relevant, I think.
Maybe you'll spot something there to help you see how it works?

--  
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)