OK, here's an oddity...I'm looking for anything to try.

(I've just now ordered an upgrade to the most current DBISAM version, will see if that fixes the problem, but this problem is occurring on 4.27 build 3.)

What I *think* may have happened:  My application was running and in the middle of a transaction. I opened DBSys and deleted some records from one of the tables involved in the transaction. Then my app crashed or was terminated by the IDE (not sure which).

Now I can open all the tables in DBSys, Verify Table, Repair table (and rebuild indexes) without problems. But my application cannot open one of the tables via a TDBISAMTable component. Here's what happens in simplified code I'm using for testing:

   ASourceSnapTbl := TDBIsamTable.Create(nil);
   with ASourceSnapTbl do begin
         Close;
                //Watching in the debugger, when the following assignment happens, the TableName
                //property goes from '' to '[a bunch of gibberish characters here]', but the DatabaseName
                //is correct afterward.
         DatabaseName := 'Company';
                //Tablename assigment is correct (replaces the gibberish)...
         TableName := 'acctsnap.dat';
                //On trying to Open the table, I get:
                //  "DBISAM Engine Error # 11010 Table or backup file  'Û•|ð®"
                //In other words, the Tablename is back to gibberish.
         Open;
         //...more code...
     end;

I have to dig out a backup of the database & see if the problem goes away when I use that. But I'd like to know what might be going on and why I can successfully open & verify/rebuild the table in DBSys but not open it in my app...because it would seem this might by a symptom of some other problem. (I don't just want to sweep it under the rug.)

Mark Wilsdorf
Flagship Technologies, Inc.
QuickBooks™ Add-Ons and Solutions You Can Use
http://www.goflagship.com

Mark


I switched to ElevateDB a long time ago but a few thoughts occur.

First is that if the table was involved in a transaction your shouldn't have been able to delete records from it. A transaction should obtain a lock on the table so no-one else can change it.

That and the fact that DBSys is just another Delphi app that uses DBISAM leads me to my second thought. Much of the time (not all but much) when this sort of thing happens the paths and hence the tables in use are different.

If that isn't the case then there has to be something to do with your app that's causing the problem. Try reducing it down to the simplest set of components that demonstrates the problem and, if they're all standard ones, email it to Tim.

Roy Lambert [Team Elevate]

Roy,

Thanks for the thoughts. I'm still in the head scratching & try this/try that phase of debugging this.

I'll post back when I know more.

Mark Wilsdorf
Flagship Technologies, Inc.
QuickBooks™ Add-Ons and Solutions You Can Use
http://www.goflagship.com

<<
Mark Wilsdorf wrote:
Now I can open all the tables in DBSys, Verify Table, Repair table (and rebuild indexes) without problems.
>>

(repeating what Roy said) but dbsys is just another app using the exact same components - hence if you are able to open the same table using dbsys then problem is definitely in your code or the way you're setting up your engine/session/database (whichever ones you have).

Since database is just a directory you then how about just placing a copy of the table in another folder and see if changing/resetting paths makes a difference in you app.


<<
Here's what happens in simplified code I'm using for testing:
>>

I tried it here with same code (using 4.30b4) and TableName property remains blank after issuing a close and of course everything works fine.

Raul

This turned out to NOT be dbisam-table related at all.

After some hair pulling & trial-and-error I finally solved the corruption I was getting by moving a bunch of local-stack TField descendants into an object.

Wierd, but it works now.

Thanks,
Mark Wilsdorf