I am currently experiencing a problem where a workstation is having problems connecting to some shared Btrieve data files.
When no other workstation is working on the data files, the problem workstation opens the data perfectly, but it does not allow any other workstation to access the data after is has opened it.
When another workstation has opened the data the problem workstation cannot access the data. It's almost as if the workstation requires sole-access. Apparently the problem started to occur after a power outage.
Other workstations do not share this problem. All workstations use Pervasive V8.
A few questions:
- Is the PSQL v8 a workgroup or server install?
- If it's a Workgroup, where are the data files? Are they on a server or local?
- WHat error do you get?
- Can you access the files using the Pervasive tools (Pervasive Control Center, Function Executor, etc)?
Certified Pervasive Developer
Certified Pervasive Technician
Custom Btrieve/VB development http://www.mirtheil.com
I do not answer questions by email. Please post on the forum.
-All the workstations use the workgroup engine.
-The datafiles are located on the a server.
-I don't have the exact error message at hand but it was something about a
file not found. I'll try to get the exact message again.
-Once another workstation has opened the data, I could not open the data on the particular workstation through the Control Centre or Btrieve utilities.
I did a bit of homework on my previously reported error.
The Control Centre error message simply stated that the microkernel cannot find 'the specified file'.
But when I used the utilities to connect to the data I received the more informative response of 'Btrieve Status 116 - Another gateway engine owns the locator file."
After a bit of searching I tried connecting to the 'server' and the gateway owner with Smart Scout. I could actually connect to the gateway owner by means of NetBIOS, but I couldn't connect to the server (TCP/IP connect error 10060).
I will try to fix the gateway on the 'server' tomorrow and see if that helps but any other suggestions would be welcome.
The problem has been resolved. It was caused by the incorrect TCP/IP settings. Apparently the DNS setting was incorrect which prevented the problem computer from communicating with the other computer via TCP/IP. Probably similar to the situation often cited as a cause for status 116 where computers seperated by router cause the same error, but I'm just guessing.