Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 20 total |
Index error 8965 |
Wed, Jan 11 2006 11:08 AM | Permanent Link |
I've just updated to DBISAM "4.22 Build 3" and I'm still getting the
DBISAM "index error 8965" reported from a test site. I upgraded because I had this error a while ago, and upgraded and see it was updated again. My app is doing multi-threaded read and writes of a database. My understanding is that this is an error that was fixed, but I don't know if I'm triggering something more, or if it is a problem in my code. Of course I find it hard to repeat it here! Essentially what I have is "two" threads. One runs and looks for work to do in the database, and the "other" is created by RemObjects calls (and hence there may be more than one). Actually, on checking I see there is another session and table set on the main form, which may be relevant. Okay, my worker checking thread does the following to create the session and tables: m_xSession := TDBISAMSession.Create(nil); m_xSession.AutoSessionName := True; m_xWorkQuery := TDBISAMQuery.Create(nil); m_xWorkQuery.SessionName := m_xSession.SessionName; m_xUpdateQuery := TDBISAMQuery.Create(nil); m_xUpdateQuery.SessionName := m_xSession.SessionName; The code that checks for something to do is as follows: if not m_xWorkQuery.Eof then m_xWorkQuery.Next; if m_xWorkQuery.Eof then begin m_xWorkQuery.Close; m_xWorkQuery.Open; end; if not m_xWorkQuery.Eof then begin SetState(csDoAction); end; result := not m_xWorkQuery.Eof; Where a result of true means there is something to be done. The SQL for the query is: szSQL := 'SELECT rsID, rsRequestTime, rsType, rsState, rsBetFairID, rsParams '; szSQL := szSQL + 'FROM RequestStore '; szSQL := szSQL + 'WHERE rsState = 1'; szSQL := szSQL + 'ORDER BY rsRequestTime ASC '; szSQL := szSQL + 'TOP 10 '; The request threads are TRORemoteDataModule derived data modules, and the session object on it has AutoSessionName set true. First key is that the main form didn't have AutoSessionName set true. Does this matter though, since it was the only one without it? The main form has a timer that, at a certain point in the day will run a query to delete old requests. queryGrid.Close; szDeleteSQL := 'DELETE FROM RequestStore WHERE rsRequestTime < '; szDeleteSQL := szDeleteSQL + Engine.QuotedSQLStr(Engine.DateTimeToAnsiStr (IncDay(Now, -14), true)); queryEmpty.SQL.Text := szDeleteSQL; queryEmpty.ExecSQL; LogReport(leInformation, 'Deleted ' + IntToStr(queryEmpty.RowsAffected)+ ' old requests'); queryEmpty.Close; queryGrid.Open; // try finally on this code removed for brevity. So the million dollar question is what might be causing the index error 8965 to be occurring now? This is rather annoying to me since I've been saying how good DBISAM is, and how it "just works", to a new employer (contract) and this is happening on their customers test system! If need be, I can let you have anything you need, but the app uses a login to a remote system to do anything useful so it is hard to replicate. All assistance much appreciated! /Matthew Jones/ | |
Wed, Jan 11 2006 11:30 AM | Permanent Link |
Okay, hold on this one a moment. Looks like the old version is still being
run... (Users, who'd have them!) /Matthew Jones/ | |
Wed, Jan 11 2006 3:05 PM | Permanent Link |
Okay, this is live again. Confirmed failing in my latest build with DBISAM
4.22. 8-( /Matthew Jones/ | |
Wed, Jan 11 2006 3:44 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
Start trying to build a demo for Tim Multithreaded apps are a nightmare! Roy Lambert |
Wed, Jan 11 2006 4:51 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< My app is doing multi-threaded read and writes of a database. My understanding is that this is an error that was fixed, but I don't know if I'm triggering something more, or if it is a problem in my code. Of course I find it hard to repeat it here! >> Can you reproduce the problem ? If so, then if you can send me the project that is causing the problem, I can take a look and figure out hat is going on. 9 times out of 10 the problem is with the coding of the threading, but occasionally it is a DBISAM bug. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 12 2006 5:04 AM | Permanent Link |
I'll try to make it repeatable, then send it to you.
/Matthew Jones/ | |
Thu, Jan 12 2006 9:40 AM | Permanent Link |
Unfortunately, I've got it to fail here too. I have an app that fires 50
threads all initiating requests, and every 10 seconds the maintenance cycle fires, deleting old items. The log shows: 14:16:50.025 0 DBISAM version 4.22 Build 3 [lots more snipped] 12/01/06 14:29:29 0 State:csDoAction 12/01/06 14:29:29 0 >>ProcessWork 12/01/06 14:29:29 0 Thread Test 14176 12/01/06 14:29:29 0 <<ProcessWork 12/01/06 14:29:30 0 State:csDoAction 12/01/06 14:29:30 0 >>ProcessWork Thu 12 14:29:30.092 0 >>Automatic maintenance cycle initiated 12/01/06 14:29:30 0 Thread Test 14177 12/01/06 14:29:30 0 <<ProcessWork 12/01/06 14:29:30 0 Deleted 201 old requests 12/01/06 14:29:30 0 <<Automatic maintenance cycle complete Thu 12 14:29:30.295 0 M:BACKGROUND ERROR: DBISAM Engine Error # 8965 Index page buffers corrupt in the table 'RequestStore' Thu 12 14:29:30.295 0 M:BACKGROUND ERROR: DBISAM Engine Error # 8965 Index page buffers corrupt in the table 'RequestStore' What is the best way for me to send you the source? The app uses RemObjects, and has the DevExpress grid version 4 (though that isn't actually vital TBH - I could easily delete it if it helps). Also Raize Components v3 is used a lot. Oh yes, and it uses SVCom to make it into a service. Thoughts? /Matthew Jones/ | |
Thu, Jan 12 2006 9:46 AM | Permanent Link |
The log segment I posted shows, by the way, a work unit (database read,
increment integer, write result to database) and a maintenance unit (delete database items more than 14 seconds old) overlapping slightly, and immediately afterwards something detects the 8965 index error and the app effectively dies (it just repeats this message forever whenever it tries to do anything). /Matthew Jones/ | |
Thu, Jan 12 2006 10:21 AM | Permanent Link |
I also note that I have a source license, so I wonder if there is a debug
version of DBISAM that might lend a clue for this? Some way of outputting a log of what DBISAM is doing so that it can be traced here? My latest test has been running for 20 minutes without failure. 8-( I've got it so that it doesn't require an account any more though, so it can be tried "standalone". It is in Delphi 7 pro BTW, if that makes any difference? Is it worth me making a VMWare image of it so that you can work on it? /Matthew Jones/ | |
Thu, Jan 12 2006 11:23 AM | Permanent Link |
More info on this perhaps:
I can get a situation where multiple threads are stuck trying to lock the table. Is this relevant? Let's go over my understanding of multi-threaded DBISAM. My understanding is that all I have to do is make sure that each thread has a separate session ID. To do that, the AutoSessionName can be set to true on forms and data modules, and that "just takes care of it". For manually created sessions, etc, I have to "wire" up the session name myself, but all that is needed is to create the session, get it to auto-name, then use that name in the queries that I create in that thread. (As per my code already posted). I've just checked this with the manual, and all is well there - nothing I'm not expecting. I'll add a log item to output the session name for each thread, but beyond that I'm open to any suggestions. Oh, and I have the madExcept dump from the lock if that is of interest. The key parts are that there is one delete, two inserts and a read all happening at the same time. Before posting this, I thought I'd be sure of my sessions names. This is odd. The main form has a session ID of "sessionServer_1". The state machine which does the work has a session ID of "sessionServer_2". All of the RemObjects data modules get a session ID of "sessionServer_3" or "sessionServer_4". Never a 5 or anything more. Okay, on printing the thread ID as well, they are always matching. I'm surprised at this given I have 50 threads in the client, but it isn't relevant to the matter in hand here - all the sessions are independent, but I can lock them and I can get error 8965. /Matthew Jones/ |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |