Btrieve C/S 6.15.451 crash

If possible, try a Maximizer backup/restore of the data files. It's possible that the first crash corrupted something and that is contributing to the subsequent crashes.

Also, if you are pushing the server engine harder of late (as suggested by your words "Suddenly as nearing licence limit"), it could be a lack of resources. I've seen NT services do peculiar things when they start to hit the wall on memory. PerfMon should be able to give you some insight into that.

Thanks for the prompt help Gord.

The problem is intermittant (8 crashes over 6 weeks)so does this indicate a file corruption problem?

Another bit of info on this one. Although the network is a fast one some (not all) NT workstations have quite long intermittant delays i.e it can take upto 15 secs for Explorer to browse the network.

Could this be a contributing factor when a client tries to create a session with the btrieve engine? Does the communication layer or engine time out with hangs? How does btrieve deal with network traffic delays.

Adrian Berman

I would start by going with Gord's advice of running through a Backup and restore, this will both remove any serious corruptions and also re-index the database (but PLEASE do a manual backup of the datafiles first because this process will overwrite your database).

Whilst in theory a slow network speed could cause the BTI microkernal engine to crash, I don't think that is the problem in the case, in most cases of bad latency the client machines will fail rather than the BTI service.

I think the most likely possabilities are that some of the BTrieve settings are wrong.

[This message has been edited by Dragonbait (edited 07 November 2000).]

[This message has been edited by Ian Wallace (edited 07 November 2000).]

When you say the server's crashing can you be a bit more specific?

Do you mean you BTI service is giving up with an Access violation? (often caught by Dr Watson)

If so I've seen this in more than one case and (sorry) it can be hard to get rid of. Have a look at the notes in the thread https://maxtalk.com/ubb/Forum2/HTML/000004.html as this discusses some similar problems.

Most recently I traced a similar problem (on a P.SQL2000 system) to MaxEdit - if you can believe it! The problem was clearly down to something to do with the transfer of chunk data when re-saving documents with embedded images over a certain size it caused the server service to die! - has anyone recently started using big bitmaps in their documents?

This sort of problem also appears to happen as a result of certain TCP/IP addressing problems.

Upgrading to Pervasive.SQL and hence the new version on Maximizer is an option however, its not guaranteed to solve this problem.

Ian Wallace
CABC

What you might want to check is
With in the Btrieve Client Server Engine
You have the Micro Kernal Monitor This will show you
1) All Active Connections
2) Max Settings / Min Settings / Current Settings

This might give you an indication on if the Server is reaching its maximum settings that are set with in Btrieve.

So the Tool is Mickrokernal Monitor
Hope that helps !

quote:

---

So the Tool is Mickrokernal Monitor

---

I wouldn't go so far as to say that the Microkernel Monitor is the tool. It is a tool that might help diagnose the problem.

However, if it is simply a matter of server engine configuration one would expect the clients to receive error codes from the server (Code XX) instead of having the server engine crash. (Although Ian quite rightly pointed out that we don't really know precisely what the original poster means by "crash".)

Thanks Guys

The crashes are BTI engine crashes which create lovely long Dr Watson reports. Ian's 0004 thread was interesting. Quite similar and most of the crashes were first part of the morning. In this case once we remove the locks and re-start the engine the system seems to perform ok until the next crash maybe some days later.

Remember, until recently the engine has performed well but see my entries (above) for general network delays.

Also at times, for no apparent reason, client NT Workstations will crash out of their Maxwin.exe with a Dr Watson's. I assume this explains why at times in the Monitor an active user is repeated 2 or 3 times. Normally they drop out after a period of inactivity (overnight).

Adrian Berman