Pervasive OLEDB - Btrieve error 85 'File Is Locked' ?

[krudler]

Any advice on this would be great - I'm going nuts.

Here's the scoop:
We have this application that uses Btrieve files (.DAT and .DDF's are present) that are on a Win2K server. The server is also running the Pervasive.SQL 2000i engine. What I am trying to do is write a simple VB6 exe that accesses one of the data files and gets 'todays schedule' and prints it out to a text file. I figured the easiest way to do this would be with OLEDB but I cannot seem to get it to connect - I always receive an error that says 'The file is locked(Btrieve error 85)'. I assume this is because the application is running, but even if I try this at off-hours when everyone is out I get the same thing.
Also, when I first started this little programming adventure I noticed that there was no database set up on the server in the Pervasive engine for this application. I was able to create one so that I could try to use OLEDB to get to the data, but I am not sure how the application is actually getting to it. I assume it must be using the API and that the only real reason the Pervasive engine is on there in the first place is so that whatever libraries and functions and junk for the API that need to be on there are there.
So...what does this error really mean, and is there a way I can get around it? And...does this mean I will have to use the API to get at what I want (plase say no, I really don't wnat to have to try to figure that out...).
Ugh.

 

[TomKane]

In the documentation that I have there is a description of 85 as below - hope it's of some help:

85: The file is locked.

The MicroKernel returns this status code in one of the following situations:

* The workstation MicroKernel has a file open, and another workstation that has the Requester loaded tries to open the same file via the server MicroKernel. The server MicroKernel cannot open the file since it cannot obtain exclusive access. The workstation that has the Requester loaded receives this status code.
* In a workstation engine environment, the MicroKernel can return this status code on an Open, Insert, Update, or Delete operation for a file under heavy usage by multiple users or tasks. The MicroKernel must momentarily have exclusive access to the file during these operations, and it retries the operation several times before returning this status code. In this case, the application can reissue the operation. In addition, you can reconfigure the workstation MicroKernel with a lower Operation Bundle Limit and Initiation Time Limit to reduce the amount of time the MicroKernel keeps a lock on the file. Refer to the User's Guide for more information about how to do this.

* In a workstation environment, a v6.15 or later MicroKernel has a pending modification (insert, update, or delete) as an incomplete system transaction in a file that has been opened in MEFS mode. If multiple users or tasks attempt to access (Get/Step) or modify (insert, update, or delete) the shared file, the MicroKernel returns this status code. An access operation can receive this status code only if the writing phase of the system transaction has started.
Reconfiguring the MicroKernel with a lower Operation Bundle Limit and Initiation Time Limit reduces the occurrences of file contention that produce this status code. Refer to the User’s Guide for more information about how to do this.

If you are a developer and want more information about system transactions, refer to the Programmer’s Guide.
* While one user has a file locked in an exclusive transaction, another user attempts to lock all or part of that file.
* When opened by a server MicroKernel, a file is in transition into continuous operation mode. Retrying eventually works.
* When opened by a server MicroKernel, two data files have the same filename but different extensions (for example, INVOICE.HDR and INVOICE.DET). One file is open and in continuous operation mode, causing the MicroKernel to generate a delta file (for example, INVOICE.^^^). The MicroKernel returns this status code when you attempt to open the second file.

* When opened by a Windows NT server MicroKernel using Microsoft File and Print Services for NetWare on behalf of a 16-bit Windows workstation, the file was also opened simultaneously by a 32-bit Windows NT or Windows 95 workstation. Doing so causes the server MicroKernel to open the same physical file using two different paths.

 

[Linda84]

A couple of questions -

How are you specifying your connection string in your VB app?

Can you successfully access the database from your workstation through PCC?

Is the file you're trying to access currently in use by the server PSQL 2000i? You can use the Monitor utility (accessible from the Tools menu in PCC) to check this.
Linda
Pervasive Software Support

 

[krudler]

I have tried both of the following connection strings with the same result:

ConnString = "Provider=PervasiveOLEDB;Data Source=Impac"
ConnString = "Provider=MSDASQL;DSN=Impac"

Today I thought, well gee, if the app is using the Btrieve API (transactional), maybe if I try using the transactional ActiveX controls then it will work instead of trying to go through the relational engine. Alas, twas not the case. Using the VADebugMode=True property I discovered that the same Btrieve error 85 was occurring in the background and preventing the control from reading the DDF.

This is all occurring on the server, so there is no remote access. The PCC on the server did not originally even have a database for the app set up in it, although it is somehow working (I assume using the API?). I was able to set one up (called Impac) in the PCC, but if I try to access it through there I get the same nasty error.

Most curious!!
Thanks for you help