Some users can't login after server crash 1

[soozle]

PSQL 2000 on NT4 SP6
The server crashed at the weekend. After reinstalling TCPIP everything (Exchange 5.5, SQL6.5) works except for a program we use called Omega which uses PSQL.
Some of the PCs can log in and out (the Omega app)at will just as they did before but a number of them just can't login at all at any time. Error numbers are 85 (file lock) and 3106/4 .
I'm assuming something's got corrupted on the server but can't pin it down. I've tried the Omega tech support but it's been 10 days of "try this, try that". Can anybody point me in the right direction?
TIA
Soozle

 

[TomKane]

3104 is something to do with connecting to the server - it sounds as though the user pc's can't access the server.

Are the configuration settings on the Pervasive engine the same as they were prior to the server crash?

Has the IP address changed for the new server?

Is the database password protected? And if so has the password changed since the server was recovered?

Is it an odbc connection that the omega app uses? If so you might be able to do an ODBC trace from the ODBC Data Source Administrator in the control panel - it might give you some idea.

Below are the descriptions for 3106 and 85

3106
The Pervasive Network Services Layer was able to establish a transport connection at the client side, but the connection attempt at the target side failed. Some possible cause are:

* The Btrieve or Scalable SQL engine is not running on the server.
* The network is overloaded.
* The connection path is invalid.
* You have more than one mapped drive to the same server.
* You are trying to access a Btrieve engine on a Windows NT server and the Accept Remote Requests setting of the Btrieve Communications Manager on that server is set to No. See the User’s Guide for more information.

85
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.

 

[TomKane]

We use P.SQL 7 - but we have this utility called Pervasive Software Monitor Utility which (strangely enough) monitors file and user access to pervasive files/tables. I'm not sure what the equivalent is in 2000 but perhaps you can use it to see how far the app is getting - e.g. is the connection being established with the database but the SQL command isn't working something like that.

Also could there be a permissions issue? Could it be that the users require certain add/change/delete rights to the database that they no longer have as a result of the new server?

 

[soozle]

Thanks for that quick reply.
The server IP address hasn't changed and pinging from all workstations using either the name or IP address is successful and the name is resolved correctly.
I'm unsure of the engine settings as this was installed by an external company but for 4 users (plus one new installation) everything works normally. I'm wondering if the broken ones were logged in when the crash happened. All users can login to the server for email and other applications. All PCs seem to have the same settings and registry entries for the pervasive software. and just to confuse me further the latest pervasive analyser says my PC (which works with the application in question) has failed all comms tests to the server <sigh>.
I'll check the BTRIEVE engine settings
thanks
Soozle

 

[soozle]

Thanks TomKane
I've watched Active Users with the monitor and the broken users just don't show up. They can all telnet to the TCPIP port on the server. I'll see what else the monitor can tell me.

BTW it's not a new server just rebooted and reinstalled the TCP/IP protocol with all settings as before.

soozle

 

[TomKane]

It's interesting what you say about &quot;but for 4 users (plus one new installation) everything works normally.&quot;

Would a uninstall/reinstall on the pervasive client s/w make any difference?

 

[soozle]

mmmmm, I tried reinstalling on one PC but didn't uninstall first. I'll give it a go.
soozle

 

[TomKane]

I was wondering how you were getting on

 

[soozle]

Hiya,
uninstalling and reinstalling got the PCs working for a short while then I realised the server had been hacked and in cleaning that up I broke it again - the btrieve server isn't running <sigh>
Thanks for all the help now I'm working on mending what I broke.
soozle