Hi there,

I am on 4.29 b2 and I am getting random errors 8963 and 9217. My suspect is that on application close, some important finalization steps may be missing. Could you give me ideas what to look for and check?

Thanks!

James,

<< I am on 4.29 b2 and I am getting random errors 8963 and 9217. My suspect
is that on application close, some important finalization steps may be
missing. Could you give me ideas what to look for and check? >>

In what context are you seeing these errors ?  Is the application
single-user, multi-user, or multi-user/client-server ?  If single-user, is
the data stored on the local hard drive ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

The application is basically "all of the above" (it can be any) and the problem occures in all modes.

Thanks,
James.

"Tim Young [Elevate Software]" wrote:

James,

<< I am on 4.29 b2 and I am getting random errors 8963 and 9217. My suspect
is that on application close, some important finalization steps may be
missing. Could you give me ideas what to look for and check? >>

In what context are you seeing these errors ?  Is the application
single-user, multi-user, or multi-user/client-server ?  If single-user, is
the data stored on the local hard drive ?

--
Tim Young
Elevate Software
www.elevatesoft.com

James,

<< The application is basically "all of the above" (it can be any) and the
problem occures in all modes. >>

You're not giving me much to go on.  Does the problem appear most often
in a particular configuration ?  Have you tried repairing the tables that
report the errors to see if they are actually corrupted ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>> You're not giving me much to go on.
I understand that being more specific would help, but these problems occur on our customers' PCs. I never experienced this on my desk. And even more, the problem is not instant. The app does not blow up with the message "Kaboom, this and that failed", the issues become noticed mostly when the app is restarted.

>>  Does the problem appear most often in a particular configuration?
I can state that the corruption occures in the single-user local configuration. I think, focusing on this particular configuration initially would be a good starting point.

>>  Have you tried repairing the tables that report the errors to see if they are actually corrupted?
Yes, the tables are repairable in most cases and sometimes even without data loss.

My question is not ask you to debug my app, but give some hints or ideas where to dig and what to check in order to make my app work more correctly with the database, ideally making these issues go away. My understanding of the potential cause of these errors to occur is improper finalization on app shutdown, leaving some changes in the memory.
Are there any settings or an API call to flush the memory buffers before disconnecting from the database?

Thanks,
James.

James


If this occurs on every site all the time then yes your software is almost certainly to blame. However, its unlikely to be anything to do with "normal" use of DBISAM otherwise Tim would be deluged with complaints.

You can call FlushBuffers manually but DBISAM does that when it shuts down anyway. You can do it after every post. It'll slow the app down but any problems will be down to OS flushing.

If your app uses threads you can double check that everything is isolated so you don't get corruption that way.

If the app is running over a network. If so then if its only on one or two machines on that network check out the network cards and cabling.

A few more questions:

What's the frequency of errors? Breakdown by single user - multi user - file server - client server.

What's the OS, hardware, and other app configuration of the machines where the errors occur.

How complex is the app?

Roy Lambert [Team Elevate]

James,

<< I can state that the corruption occures in the single-user local
configuration. I think, focusing on this particular configuration initially
would be a good starting point. >>

With single-user applications, this is usually down to an issue with
improper shutdowns of the machine during, or very close after, usage of the
DBISAM application where data was modified.   Windows can cache modified
file system buffers, so it is possible that the modified file system buffers
are still in memory when the shutdown occurs, thus resulting in data loss.

The way to get around this is to make sure that you periodically call the
TDBISAMTable/TDBISAMQuery FlushBuffers method to force Windows to flush data
to disk, or to use transactions with the default Commit method call, which
will also force a flush of the buffers to disk during the commit.

You can read up more on this here:

http://www.elevatesoft.com/supportfaq?action=view&category=dbisam&question=corrupted_tables

and here:

http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=d&version=7&topic=Buffering_Caching

--
Tim Young
Elevate Software
www.elevatesoft.com