Btrieve

Hi Mike,

If the NT server module of btrieve crashes the error 3 that follows (or something similar) is pretty inevitable as the clients have nothing to talk to. Its a bit annoying that there will be loads of these to click through as Maximizer has many files open and they all raise an error.

First Have you got the btrieve 451 Patch loaded. This is a must. You can get the file from
http://www.pervasive.com/support/updates/upd_btrieve.html

Make sure the updated DLLs are copied to all workstation Windows\system or Winnt\system32 folders.

Most sites where this btrieve software is loaded have few problems and the service will run for months without problems. Having said this, I have seen the problem where the NT service just dies and it can be difficult to eliminate. The real problem is that Pervasive no longer support btrieve 6.15 so there's only so much one can get help from them. My suggestion in the long term will be to upgrade to Pervasive.SQL 2000 which is the standard database engine in the new version of Maximizer Enterprise 2000.

I think my suggestion now is probably to get the server as 'clean' as possible in installation terms. What else is running on it?

I hope this helps.

Ian Wallace
CABC

quote:

---

First Have you got the btrieve 451 Patch loaded.

---

Yes, I have the Btrieve 451 Patch loaded.

quote:

---

I think my suggestion now is probably to get the server as 'clean' as possible in installation terms. What else is running on it?

---

Btrieve is currently running on an almost completely clean system. I reformatted a machine I had lying around, installed NT Server and got it up to SP-6a and installed Btrieve. No luck.

The problem occurs semi-randomly. It will run fine for a couple days, then crash half a dozen times in an afternoon. For clarifications sake, the DLL's that must be present on client machines are "WBTRV32.DLL" and "W32BTICM.DLL"?

Mmm you seem to be doing the right things.
I normally copy all the Dlls from BTI\WINNT\WIN32 to each PC for saftey but I think your right they are not actually all necessary.

SP6a I've not seen, but I expect its OK I do know that SP4 is not a good idea.

In the instance when I've seen a similar problem Dr Watson usually shows that the problem is in code that seems to be processing record locking.
I'm not sure if there's something else happening to trigger this at one of the clients such as maybe some old network DLLs. Out of interest and this may seem a very odd question have any of the PC's every used ACT on the network?

Are you running Max Exchange on the server? Its not stricly recommended on the server (see another thread) but usually causes few problems.

Which protocols are you running. Unless you have to run IPX I should stick to TCP/IP.

I guess the other thing is to ask how did you decide how to set up your btrieve server settings? Was it set up by a Maximizer business partner?

The difficulty as I indicated before is that Pervasive are no longer interested in 6.15 making this very tricky to solve other than by a process of elimination in the configuration.

Ian Wallace

Thanks for the help Ian. Very muchly hugely greatly appreciated. I will name my first-born child (boy or girl) after you if you can help me work through this.

quote:

---

SP6a I've not seen, but I expect its OK I do know that SP4 is not a good idea.

---

Y'know, I had service pack 4 installed before I upgraded to service pack 6. I wonder...

quote:

---

In the instance when I've seen a similar problem Dr Watson usually shows that the problem is in code that seems to be processing record locking.

---

I'll be honest with you. I'm not really confident in my ability to read Dr Watson files. I do have a couple lying around from different crashes if that would help?

quote:

---

I'm not sure if there's something else happening to trigger this at one of the clients such as maybe some old network DLLs. Out of interest and this may seem a very odd question have any of the PC's every used ACT on the network?

---

The clients are relatively new, all running Win98 (first edition). I am running TCP/IP exclusively (before I upgraded the client machines I ran NetBEUI). I have never ran ACT on any machine. I was running Maximizer 5.0 before I upgraded to Maximizer Enterprise 5.0 .

quote:

---

Are you running Max Exchange on the server? Its not stricly recommended on the server (see another thread) but usually causes few problems.

---

Not running MaxExchange on server.

quote:

---

I guess the other thing is to ask how did you decide how to set up your btrieve server settings? Was it set up by a Maximizer business partner?

---

It was set up by myself. My company is based
in Prince George, BC, Canada. We live in a relatively small town; no Maximizer business partners remotely near us.

I based the initial settings for Btrieve off of a document in the knowledge base at Multiactive. (Sorry, I don't have the URL handy)

quote:

---

Originally posted by Mike_Carr:
Thanks for the help Ian. Very muchly hugely greatly appreciated. I will name my first-born child (boy or girl) after you if you can help me work through this.
)

---

I would be flattered… but… I’m very happy just to have you using our new Max Talk site.

I’m afraid this is not a simple problem, you’ll need to cross possibilities off one by one. Here’s a few more thoughts…..

If you followed Multiactive settings for your btrieve you should be OK. Again it sounds like you’ve done all the right things.

I think its unlikely to be the cause of this problem, but you should avoid filepaths to your data that contain spaces. Preferably keep to 8 characters or less on a mapped drive.

I suspect were looking for something less obvious like maybe a PC with a really nasty BIOS powersave routine that cuts off btrieve mid conversation. (These usually just cause nasty messages to appear in Maximizer like… “Sunday OK” when the system comes back on.) Possibly its just a rouge PC or network card.

Though again I’m not sure it’s the cause, try to ensure all your network cards use the manufactures‘
driver. Avoid loading ‘NE2000 Compatible’.

It may be worth setting the following registry entry on all machines just to ensure that Btrieve does not even dream of IPX/SPX.
HKEY_LOCAL_MACHINE\SOFTWARE\Pervasive Software\Communications Requester\Version 6.15\Settings

Supported protocols=TCPIP

The last time I saw a problem similar to this, it was often discovered first thing in the morning. Is there any pattern at all to your crashes? What other things were users doing at the time?

By all means email a Dr Watson File to support@cabc.co.uk, though I agree most of contents is hard to get real information from!

Ian