This is more for reference - and maybe it might help someone else.

I ran across a problem today where I was getting this message (followed up with list index out of bounds, and access violation errors) when a thread that calls an independent Session, Database and Query was being terminated.

Within the thread I was calling Query.close before exiting, but for one clients particular data it didn't want to play ball.

In the end, I found the solution which was to call Query.Unprepare after calling Query.close

I'm not sure if this is standard practice for closing, or if there's something unique to this particular data (as many other clients are running the same script without issue), but figure this may help someone in the future when searching for a similar issue. (Probably myself when I forget about it 3 years from now)

Adam,

<< I ran across a problem today where I was getting this message (followed up with list index out of bounds, and access violation errors) when a thread that calls an independent Session, Database and Query was being terminated. >>

Is this with a remote session, or a local session ?  If you can send me an example that replicates what you're seeing, I can take a look.  This sounds like a bug, and I'd like to get a look at it and run it, if you can help.

Tim Young
Elevate Software
www.elevatesoft.com

We've been getting a very similar sounding error, but only from one customer. The madexcept trace reads:

madExcept version : 3.0k
callstack crc     : $8dcedaba, $a51de303, $4b943731
exception number  : 1
exception class   : EListError
exception message : List index out of bounds (23).

main thread ($1738):
00474c79 +0015 BodyPlus.exe Classes       2736   +1 TList.Error
00474cdd +0039 BodyPlus.exe Classes       2741   +1 TList.Error
00474bf4 +002c BodyPlus.exe Classes       2718   +2 TList.Delete
0053d10f +001b BodyPlus.exe dbisamen                TDataDirectory.RemoveQueryStatement
004c9920 +0010 BodyPlus.exe dbisamsq                TQueryStatement.Destroy
00404614 +0008 BodyPlus.exe System        8313   +1 TObject.Free
0058c499 +000d BodyPlus.exe dbisamtb                TDBISAMQuery.FreeStatement
0058c457 +004b BodyPlus.exe dbisamtb                TDBISAMQuery.SetPrepared
0058cec4 +0050 BodyPlus.exe dbisamtb                TDBISAMQuery.SetDBFlag
0058861a +0012 BodyPlus.exe dbisamtb                TDBISAMDBDataSet.CloseCursor
004b8bf3 +00a7 BodyPlus.exe DB            8849  +21 TDataSet.SetActive
004b89f8 +0004 BodyPlus.exe DB            8801   +0 TDataSet.Close
01074715 +0279 BodyPlus.exe UpdWork       2261  +40 TfrmUpdWork.Load_Refer
0111e537 +04b3 BodyPlus.exe LoadJobCard   4104  +45 LoadCustomerTab
0108cbc1 +3a8d BodyPlus.exe UpdWork       7897 +732 TfrmUpdWork.ActionOK
010864fd +0141 BodyPlus.exe UpdWork       6314  +28 TfrmUpdWork.WMActionKey

the function call at line 2261 of UpdWork is a simple call to
 selRefer.Close;

where selRefer is a TDBISAMQuery component with an SQL that has 1 parameter. ParamCheck is set to true and the results of the sql have just been iterated through in a loop. The last call to the query prior to it's close would have been selRefer.Next; as part of that loop.

There are other examples with different queries, and the bug only appears to happen randomly. The only comonality I can see is they are all queries with parameters.

The DBISAM version we are using is 4.35 Build 1

Hope it helps!

Eric,

<< The DBISAM version we are using is 4.35 Build 1 >>

I'll have to check this against the latest.  Can you send me an example that replicates this ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Sorry for the delay in replying - I didn't log back onto the website to follow up, and have just done it now that the problem has resurfaced.

I'm running the latest version (Version 4.43b1) on XE2 and have seen this error again.

This is on a local session.

I'm seeing the same symptoms as before:

Table or backup file '' does not exist.

and, interestingly enough "Integer Overflow" as well.

I'd love to give you an example to replicate the problem - but this is posing to be a difficult one to trap, let alone create a demo of.

For instance, if I put in breakpoints in my code and trace - it seems to work OK, but when I run through without break points it misbehaves. It only seems to misbehaves when I'm not looking at it in detail. (Maybe it's got something to do with quantum physics and light behaving as waves or particles )...

I've thrown a couple more unprepare statements in against a few queries which appears to have fixed the issue again.

In my case I'm not using parametrized queries, which tends to contradict the issue Eric is having.

Cheers

Adam.

Adam,

<< Sorry for the delay in replying - I didn't log back onto the website to follow up, and have just done it now that the problem has resurfaced. >>

Can you email me the code that you're using to set up the session, database, and query in the thread ?  If you can email me all of the related code, that would be great.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Please leave with me. I'll need to strip down with what's involved with the specific module / thread but will try and get this to you as soon as I can.

Best Regards

Adam.

Good Afternoon Tim,

My apologies for the delay in getting back to you regarding this. In the process of creating a demo application to send to you that recreates this I found some glitches in my code.  

I've applied some changes back to my code to see whether or not this fixes the initial issue I was facing.

If it does - egg and my face are one.

If it doesn't - I'll at least have a working demo application I should be able to send through to you as an example on how I am creating my thread that will hopefully create a problem sooner or later.

Best Regards

Adam

Adam,

<< If it doesn't - I'll at least have a working demo application I should be able to send through to you as an example on how I am creating my thread that will hopefully create a problem sooner or later. >>

No problem, if you're still seeing the issue, just send over something and I'll take a look.

Tim Young
Elevate Software
www.elevatesoft.com

Eric,

Following up on this:

Since you posted this, we've had some reports of issues with multi-threading and closing of databases in certain component ownership situations where a session owns the databases and the session is freed before the databases are closed/freed, but nothing with respect to queries.

The latest DBISAM 4.43 B3 fixes these issues.

Tim Young
Elevate Software
www.elevatesoft.com