hi there,

we have issues with one customer who continuously getting corruptions in one specific table.

To see what other users are currently logged in to a database, we created a table "dbinuse".  the only and primary key consist of username:string moduleid, processid:integer.  this table also has fields for login and heartbeat both datetime.  a timer in the application (delphi 7) updates the heartbeat field via an sql update statement every minute. with around 5000+ customers this works perfectly fine - most of them are single user customers. but this one customer encounters 8965 index corruptions quite regularly if he is logged in with more than one user - the maximum users logged in at the same time at this site is 5.  
the customer uses a ms terminal server environment, which is used by other customers without a problem.

what can cause this error?

thanks for your help,
klaus

Hello,

There are many possible causes, it's hard to say without detailed information, the obvious answers being it can be his network hardware or incorrect settings at this client, like mixing clients with the "LargeFileSupport" property enabled with clients that do not have it enabled. What version are you using, and are you using Client/Server or File Sharing?

--
Fernando Dias
[Team Elevate]

hi fernando,

sorry for missing out these facts.  we are running dbisam 4.32 build 1 in a file sharing environment.  all clients access the app/db through the same terminal server, what excludes any mixing of settings.

i don't believe that this is a hardware issue, because this one table causes us grieve. the other 100+ tables are fine.

we just encountered a case, where there was only one user logged in for about 6.5 hours and the index got corrupted.  i can't say when this happened exactly, because dbisam doesn't report a corrupt table immediately. before a certain piece of business logic is run, we implemented a verify of the tables to prevent processing of corrupted data.
so what happened to this table is inserting a record into an empty table.  then updating the table about 390 times writing modified data into a non indexed field.  sometime down the road the index buffers got corrupted - the verify states: indexes do not match record data

if you need any more information, please advise me what i am to supply.

regards,
klaus

Chris,

One more question: Are you getting any #8965 errors?
If you are not mixing settings it might be a damaged ".dat" header - try to replace that table and replace it with a table from another client or a newly created one.
If that doesn't help, then I would say it's some environmental thing, such
as a disk problem, Anti-Virus software or something like that.
In any case, you should send a copy of the table to Elevate support.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

Chris,

One more question: Are you getting any #8965 errors?
If you are not mixing settings it might be a damaged ".dat" header - try to replace that table and replace it with a table from another client or a newly created one.
If that doesn't help, then I would say it's some environmental thing, such
as a disk problem, Anti-Virus software or something like that.
In any case, you should send a copy of the table to Elevate support.

--
Fernando Dias
[Team Elevate]

hi fernando,

yes the client encountered a #8965 error.  we already tried to just delete the table and have it recreated, which is implemented in terms the files do not exist.

an environmentally cause can't be ruled out completely, but is most unlikely.  the data resides on a fileserver using a raid array.  the customer is serviced by an it company which doesn't make it unfailable, but at least people with a certain knowledge are involved. and these guys seem to be good.

av software is available on client and server, but excludes either app and data folders.

is there any other cause resulting in a reported #8965 error?
we are flushing the database at several points (business logic wise) in our app. may this be a problem?
we are using only one db session in the application.

a copy of a corrupted table is attached.

thanks,
klaus

klaus,

<< is there any other cause resulting in a reported #8965 error? >>

Improper server shutdown, but from what you said it's not likely.
File locking issues at the OS level, perhaps but it's hard to tell as you don't seem to have issues with any other table. I don't use File Sharing mode anymore, except for single user applications, but I do remember that there were sometimes problems caused by OS locks - thats one of the advantages of using Client/Server.

<<we are flushing the database at several points (business logic wise) in our app. may this be a problem?>>

I don't see how... how are you flushing the database?

<<we are using only one db session in the application.>>

That is not a problem at all.


--
Fernando Dias
[Team Elevate]

When you say its working everywhere else and it is not the environment here cause the problem - that sounds strange.  It one users only causes this - then hardware - bad memory, network card other crap can affect - but this is rare - but it does happen.

If the users - meaning the Terminal Server sessions are Vista or Windows 7 OS, have SMB 1 set .

We have had a few customers who have experienced issues with Windows 7 with respect to SMB.  Once they set the SMBv1 protocol the issue was resolved.  Here is a link explaining SMB setup.

http://support.microsoft.com/kb/2696547

Walter

Klaus,

<< we have issues with one customer who continuously getting corruptions in
one specific table. >>

Please contact support@elevatesoft.com and open a support session.  This is
not the proper venue for diagnosing/resolving such issues.

Tim Young
Elevate Software
www.elevatesoft.com

Klaus,

<< so what happened to this table is inserting a record into an empty table.
then updating the table about 390 times writing modified data into a non
indexed field.  sometime down the road the index buffers got corrupted - the
verify states: indexes do not match record data >>

DBISAM does not update indexes when non-indexed fields are updated, so what
you're saying is that the index became corrupted with a single insert.  As
you can imagine, this is not possible, so something else must be accounting
for the issue.  As I said in my other message, please open a support session
so that we can pursue this in more detail via email.

Tim Young
Elevate Software
www.elevatesoft.com

On 14.01.2014 23:57, Chris wrote:
> Fernando Dias wrote:
>
>> Chris,
>>
>> One more question: Are you getting any #8965 errors?
> ...
>
> yes the client encountered a #8965 error.  we already
> tried to just delete the table and have it recreated,
> which is implemented in terms the files do not exist.
>

Maybe farfetched, but:
If there is a bad spot on the disk, maybe you are re-using that spot
after deleting the old file. Maybe renaming the files of the corrupted
table, and then creating the new table (on a supposedly healthy area).

If you look at the corrupted index file, does it look like an index file
or is it all just rubbish?


--
Aage J.