System Error 115.23.0 - PSQL 2000i (SP4)
Brendt Hess
Generally, we are receiving it from 0 to 3 times a day. To the best
of my ability to check (we have a large codebase, with multiple
programs accessing the DB), we have not changed any code related to
this file in a way that could cause this.
There are no program errors that are being related to this error -
that is, no program has generated an error any time near these
incidents that is even possibly related to an error on this file, and
in most cases, there are *no* errors recorded at or relatively near
the time that the error is generated.
We have used the Rebuild utility on the file to no effect - the errors
continue. Is this a known issue? Is there anything that I can do to
track this down?
Environment: PSQL 2000i (SP4) on Novell 5.x, ~200 active clients on
Win9x machines (a few Win2K machines as well), running a mix of
Btrieve and PSQL ODBC applications (3-4 connections per user). Files
open: Peak 130, avg 112. Handles: Peak 14,400 Avg 13,000.
Below is a sample PVSW.LOG entry:
05-20-2002 07:53:52 NWMKDE 0000004A NWMKDE.NLM DBSRVR
I System Error: 115.23.0 File:
LIVE1:DATA/WOP.DAT
Thanks in advance
Bill Bach
"Wrong page type found in a version 7.x file."
I don't know for sure what this means, but I can guess, given the
context. (I'm including all the techie detail, in case you need it. See
*Btrieve Complete* for explanations, if needed.)
The Btrieve operation is 23, which corresponds to a GetDirect operation.
GetDirect is used to read a record directly from a given record pointer.
If the file is in 7.x format, then this will be split into two fields -- a
3-byte Logical Page Number and a 1-byte Record number. When the engine
gets this call, it takes the logical page number and does a look-up into
the Page Allocation Table (PAT) to obtain a physical page number. You
would agree that this page should be a DATA page, right? My guess is that
if the record position is damaged or otherwise corrupted, it will specify
an incorrect page. If it loads an INDEX page instead of data, I would
expect the engine to toss out this error.
Why does the app not throw this as an error? Perhaps the app KNOWS that
it may spew a bad GetDirect from time to time. In this case, it accepts
the Status 43 returned to it by the engine and simply moves on.
On a lark, I tried to duplicate this on my WGE, but I couldn't get this
error to appear -- but it could be more specific to the NetWare engine.
If you can, try doing some GetDirect calls from the Function Executor and
provide bogus data. Try values for the first 4 bytes of "00 02 00 00", or
"00 03 00 00", etc. This will pull the first record (record 0) from page
2, page 3, etc. Since one or more of these pages will NOT be a data page,
you should eventually get a Status 43 from WBEXEC32 -- and hopefully get
this error on your NetWare log.
Of course, you can always enable MKDE tracing on the GetDirect operation
and wait until you get a failure -- then see what is actually being
called....
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
Bill...@goldstarsoftware.com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: July 15-18, 2002 - See our web site for details!