Hi

Recently we started to receive the error 'Header information corrupt' on a specific table the repair fixes the issue but it seems to come back again almost every week.

I was wondering if you can get the error if you were to shutdown the computer or stop the service from running while DBISAMServer is running with connected sessions. If so, is it only if the sessions are reading or only writing or both?

Obviously its in client/server.

any ideas would be great for what to look for, thanks...

<< Recently we started to receive the error 'Header information corrupt' on
a specific table the repair fixes the issue but it seems to come back again
almost every week.

I was wondering if you can get the error if you were to shutdown the
computer or stop the service from running while DBISAMServer is running with
connected sessions. If so, is it only if the sessions are reading or only
writing or both? >>

No, the DBISAM Database Server will wait until the sessions are all
terminated before terminating itself.  The only exception to this would be a
situation where the service is still waiting, and the OS goes ahead and
kills the task outright because the OS is shutting down.

Does the customer constantly shut down the server machine ?  If so, then
that's probably not a good idea, especially while users are still using the
database server.

--
Tim Young
Elevate Software
www.elevatesoft.com

"ClockOn" wrote in message
news:5E7445D2-B7B0-4200-8721-4AE96AB17F0E@news.elevatesoft.com...
>
> Obviously its in client/server.

I find the remote connections to be very robust. I think the only time the
tables appears to corrupt is when there are power outages to the server
computer for which i try to ask the end/user to invest in a UPS for the
server at least.

If you have not already done so, you can significantly minimize exposure by
using the Table.FlushBuffers. For example, flushbuffers after a data form or
dialog closes and the tables are posted. Performance penalty is hardly
noticable at this point.

When programmatically updating tables like iterating and updating tables,
only flushbuffers after posting the last record. Or better yet, do the
updates within a database transaction/commit/rollback.

Also don't forget to confirm that ALL connections are remote and you don't
have a mix of some opening the tables locally while others are remote
connections.


Regards
--
Gregory Sebastian

Hi thanks for the responses.

The server does have a batch file to stop the DBISAMServer at night for backups, scans, etc... but this shouldnt be a problem should it? Because its using the Windows "SC Stop" command which i would think would allow the service to close 'gracefully' but tell me if you think otherwise...

If the service process is 'killed' would it only cause corruption if the client was in the middle of a write or read or doesn't matter?

bump...

<< The server does have a batch file to stop the DBISAMServer at night for
backups, scans, etc... but this shouldnt be a problem should it? Because its
using the Windows "SC Stop" command which i would think would allow the
service to close 'gracefully' but tell me if you think otherwise... >>

No, a normal service "stop" should be fine.  Did you check the Windows event
log to see if there were any abnormal shutdowns/restarts, etc. in there ?

<< If the service process is 'killed' would it only cause corruption if the
client was in the middle of a write or read or doesn't matter? >>

It would only cause issues if the server was in the middle of a write to a
table file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ok thanks Tim I thought as much but wanted to just confirm everything. The service is stopping correctly so it must be something else. We do hav a number of tables but only one is consistently affected so I'll just investigate that a bit more. If you think it could be anything else let me know. Thanx 4 the help...

I don't suppose that the one table consistently affected is generally updated by one workstation is it?

Roy Lambert

Roy Lambert wrote:

I don't suppose that the one table consistently affected is generally updated by one workstation is it?

Roy Lambert



It is one computer but it's a terminal server with about 20 connections and the table is used as an audit trail so all the users are constantly updating it. But what were your thoughts?

ClockOn


Just that it could be down to network cards or cabling or even PC configuration.

Roy Lambert