I have virtually next to no experience with Pervasive software, so my
apologies first off for being so clueless.

I'm running Pervasive.SQL 2000i SP3 on Windows Server 2003 SBS SP1.
It's our database backend for Great Plains Dynamics 6 frontend, which
I've inherited.

The users will be plugging away and all of a sudden they will get the
DB errors on their screens and GP quits working with errors 3006 and
3111.

I'll have to stop and then restart the transactional and relational
services and then everything will be fine again.

This is the error in the Event Viewer:

Faulting application NTDBSMGR.EXE, version 7.90.230.36, faulting
module w3odbcei.dll, version 7.90.230.36, fault address 0x000348d5.

And these are the entries in PVSW.log around the time Pervasive
crashed again:


10-22-2004 11:08:25 W3COMSRV 00001870 NTDBSMGR.EXE NTSERVER1
E WinSock socket() error=10047.
10-22-2004 11:08:25 NTMKDE 00001870 NTDBSMGR.EXE NTSERVER1
I Error initializing the SPX protocol.
Error code: 11.
10-22-2004 11:08:48 NTMKDE 00001870 NTDBSMGR.EXE NTSERVER1
I Resources allocated
10-22-2004 11:10:01 NTMKDE 00001870 NTDBSMGR.EXE NTSERVER1
I Resources released
10-22-2004 11:10:12 NTMKDE 00001870 NTDBSMGR.EXE NTSERVER1
I Resources allocated


Can anyone give me any insight into this problem?

Hi Joseph,

I have had many clients running under P.SQL 2000i and Dynamics v6 without any
problems. The variable is the Win 2003 server.I have included the Pervasive
definitions for your error messages below. It seems that the problem is server
related.

Lyle

3006: The MicroKernel router detected an invalid
session
The session information contained in a position block is invalid.
This status code occurs for one of the following reasons:

The application is trying to use a position block for a file that
resides on an engine and for which the connection has been
previously terminated via a B_STOP (25) or B_RESET (28)
operation.

The application is trying to use a position block for a file that
resides on a remote server and that encountered an abnormal
network error on a previous operation.


3111: Failure during send to the target server
The Pervasive Network Services Layer attempted to send an
application request to the target server and encountered a network
specific error from the target. Check the Pervasive Event Log
(PVSW.LOG) for more information.
You may receive this error when attempting to connect to a
Workgroup engine on Windows 95 if the machine has not been
upgraded to Winsock 2. If you are not running Winsock 2 on your
Windows 95 computer with Workgroup engine installed, you should
download the WinSock 2 update from Microsoft: http://
http://www.microsoft.com/windows95/d.../wuadmintools/
s_wunetworkingtools/w95sockets2/default.asp?site=95.
Status Codes
Note If there is a problem with AutoReconnect, a further status code
3131 will be issued.

On 22 Oct 2004 09:18:07 -0700, joe (AT) josephmarkovich (DOT) com (Joseph Markovich) wrote:

I had this problem in the past with a similar product to great plains, it
was a problem with the dns server settings as far as i remember.


<someone (AT) nowhere (DOT) zz> wrote

Your error messages in the PVSW.LOG are not related. They are showing up
on startup because you have the server engine configured to support SPX,
yet you do not have SPX enabled. To get rid of these, get rid of the SPX
entry in the "Communications Protocols" configuration setting.

As for the problem of the engine crashing, this is a known issue,
especially if you are hitting the database with SQL/ODBC queries for
reporting (like from Crystal). Check with your users to see if the
crashes always come during/after running specific reports from the ODBC
side of the database.

1) The cheapest suggestion is to upgrade to PSQL2000i Service Pack 4 on
the server (v7.94).
2) If that fails, there may be some additional (untested) fixes that can
be helpful. However, they will not be as stringently tested as a full
Service Pack.
3) The best suggestion is to move to the Pervasive.SQL V8 database engine,
which will also support your GPD environment, but since it is currently
supported by Pervasive Software, it will be possible to get a reliable fix
to any crashing issue you are seeing. (Or, perhaps, the issue was already
resolved, since there have been multiple releases of PSQLV8 already.)
The cost of this upgrade is dependent on the number of database users you
have. See your local Pervasive reseller for pricing, or let us know and
we can get you pricing for the upgrade.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: November 16-19, 2004: See our web site for details!


Joseph Markovich wrote:

I will keep looking into if something the users are doing in Dynamics
or FRx or Access is causing this.

Because of my lack of experience with Pervasive, I am pretty scared to
install SP4 for 2000i. I don't have a testing machine to run it on
here and I am scared that I am going to muck up my production server.
Will SP4 possibly eliminate this problem? I am not sure if it is
reporting that is crashing this. We are not using Crystal here (why I
have no idea), but I know there is an ODBC connection on the Terminal
Server that all the thin clients are using to connect to the main
server. Plus there are a ton of these Access applications that are
using ODBC to pull data out of Pervasive. I'm sure there are some
"best practices" or standards everyone should follow and I also know
that what we're doing here is not it.

The users told me that the GP never did this when they were running 2k
servers. Once the change to Server 03, this started.

Any words of encouragement or support would be appreciated.

On another note, clearing up the protocol mess and just using TCP/IP
has ended all those errors in my Pervasive logs. Just thought I'd
share that since it was a huge accomplishment in my eyes.

-Joe

Bill Bach <bbach (AT) cncdsl (DOT) com> wrote

I will keep looking into if something the users are doing in Dynamics
or FRx or Access is causing this.

Because of my lack of experience with Pervasive, I am pretty scared to
install SP4 for 2000i. I don't have a testing machine to run it on
here and I am scared that I am going to muck up my production server.
Will SP4 possibly eliminate this problem? I am not sure if it is
reporting that is crashing this. We are not using Crystal here (why I
have no idea), but I know there is an ODBC connection on the Terminal
Server that all the thin clients are using to connect to the main
server. Plus there are a ton of these Access applications that are
using ODBC to pull data out of Pervasive. I'm sure there are some
"best practices" or standards everyone should follow and I also know
that what we're doing here is not it.

The users told me that the GP never did this when they were running 2k
servers. Once the change to Server 03, this started.

Here's an example of what just happened a few minutes ago. I had to
restart the server unexpectedly because of Exchange. It restarts
everything loads, and it's fine. However, right before the restart,
this appeared in the Event Log twice:

Reporting queued error: faulting application NTDBSMGR.EXE, version
7.90.230.36, faulting module w3odbcei.dll, version 7.90.230.36, fault
address 0x00012ca1.

Then after the restart the dreaded Application Error (again):

Faulting application NTDBSMGR.EXE, version 7.90.230.36, faulting
module w3odbcei.dll, version 7.90.230.36, fault address 0x00012ca1.

Is there a chance that SP4 will take care of this? We're not going to
sink any money into v8 because eventually I am supposed to upgrade
this to GP v8.

Any words of encouragement or support would help!

-Joe

Bill Bach <bbach (AT) cncdsl (DOT) com> wrote

If you go to the patches page for 2000i and look at the history notes
there are a couple of SQL engine crash issues that were fixed.

If you are not getting anything besides the SPX errors (now cleared
up) in the pvsw.log SP4 would be a good direction to go.
Pervasive.SQL 2000k SP4 was a bug fix only release and is pretty
solid. Definitely recommended.

Leonard

On 27 Oct 2004 13:33:11 -0700, joe (AT) josephmarkovich (DOT) com (Joseph
Markovich) wrote:

I have more questions now from looking at the Pervasive logs again:

Yesterday, Pervasive bombed at 2.47p. At 2.55 this was put into the
Pervasive log file:

10-27-2004 14:55:33 NTMKDE 00000D7C NTDBSMGR.EXE NTSERVER1
I The file
E:\APPS\DYNDATA\SYSTEM\SY01402.BTR is rolling back.
10-27-2004 14:55:33 NTMKDE 00000D7C NTDBSMGR.EXE NTSERVER1
W The log file is corrupt.

This morning Pervasive bombed again at 8.42a and this was put in the
Pervasive log:

10-28-2004 08:54:37 NTMKDE 00001B50 NTDBSMGR.EXE NTSERVER1
I The file
E:\APPS\DYNDATA\OEA\PURCHASE\POP10100.BTR is rolling back.
10-28-2004 08:54:38 NTMKDE 00001B50 NTDBSMGR.EXE NTSERVER1
I The file
E:\APPS\DYNDATA\OEA\PURCHASE\POP40100.BTR is rolling back.

Are these more clues as to what someone was doing before it crashed
and possibly what they were doing crashed it?

I'm going to install SP4 on the weekend also...

Any more ideas from anyone? I totally appreciate everyone's input
thus far!

-Joe


Leonard <lharvey (AT) austin (DOT) rr.com> wrote

The "Log File Corrupt" error may have to be dealth with in this way. First, shut down cleanly. Second,
delete all files from C:\PVSW\BIN\MKDE\LOG. Then, restart.

The "Rolling Back" messages tell you that the database was in the process of updating this file when the
server crashed. It detected that the file was in an "unstable" state, and it rolled it back to the
previous system transaction (checkpoint). It is more informative than anything, but it does tell you
that record changes may have been lost in this file.

Definitely get SP4 in...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: November 16-19, 2004: See our web site for details!



Joseph Markovich wrote: