Hi, I hope someone can provide a little guidance on this.

I'm posting regarding an error a client of mine is getting in their
NDCLytec application, which uses Pervasive as a back end.

I'm posting regarding this problem because (a) it seems to me the
problem is primarily a database problem, not an app problem, (b) I've
seen one or two questions about Lytec pervasive databases, and Pervasive
in general, here before, and (c) my client is looking to avoid the
expense of the support contract from the reseller if possible.

Sorry for the preamble. The error is: "Error in File: Logged In User,
Operation -9992, Error Number -1, Access Violation". Sometimes the
numbers change (probably just the operation number).

Users get this error when logging in. They didn't always get it. I
also get the error when trying to connect to the database using the
standalone pervasive database management tool that came with Lytec.

(This is the real concern actually; I was asked to create some custom
reports, and I figured I could try an ODBC connection with an Access
database, but the ODBC connection won't work at the moment, I guess
because of the error.)

The error does not prevent users from connecting to the database through
Lytec, but it does prevent one from opening up the Lytec database via
the management tool.

Version: PervasiveSQL 8.60 (Lytec 2005).

I'm wondering if it might be possible to work around the error by
installing lytec onto another machine and then moving the database files
into the new installation. If anyone can confirm whether this
would/wouldn't work, or another way to solve the error and/or connect to
the Pervasive db via odbc, I'd be much obliged.

thanks,
spark

Moving the database to another computer probably will not help unless
there is an actual probelm with the computer it is currently one. If
you have a corrupt database file then you need to repair it. If you
just have bad data then you will have to resolve that.

You could run bUtil to dump your data out and if you get an error 2
then you have a corrupt file. You can also download BtSearch at
www.nssdd.com to review your data. If you get an error 2 on any file
then you have a data corruption.

Have you tried saving your current data and going back to a backup to
see if that solves the problem?

Gil

spark wrote:

Thanks for the reply Gil. Responses inline.

In article <1154102500.381000.153750 (AT) 75g2000cwc (DOT) googlegroups.com>,
nelsonsoft (AT) nssdd (DOT) com says...
I assume that bUtil is a Pervasive tool that I should find in the same
directory as the Pervasive db manager tool?

I've dl'ed your search tool and I'll give it a whirl, thanks.

My client is pretty unsophisticated, and I doubt that they have been
creating backups, but I will check. If I'm lucky enough to find one
that does not have the error, is there a tool that will transport the
new data into the old copy?

spark

You would have to repair the newer file in order to extract data from
it. If you want to check for a corruption BtSearch will allow you to
scan an entire directory and performs a scan on each file and will
report back any error if it fines one.

Gil

spark wrote:

Hi,

Neither the Operation Number nor the Error Number are Pervasive errors.
All that means is that Lytec is probably mapping the Pervasive Status
Code to something of their own definition.

So the only meaningful (to us) piece of the error message is "Access
Violation". This does not indicate a corrupt or damaged file.

If the error does not prevent Lytec from functioning, but prevents you
from connecting to the database via ODBC, that points to something
about the DDFs.

I think that one or all of the DDFs is either locked by the O/S or
opened exclusively by some process.

First thing to try:

Run the Pervasive Monitor when all users are out of Lytec. If you are
not at the server, connect to the server (Options | Connect). Under
Microkernel, select "Active Files". If you see in the list either "<db
path>\file.ddf" or "<db path>\field.ddf" or any other .ddf files, click
on it and look in the list on the right for the name of the current
users. Determine if that user is actually using the system at that
moment. If not, select "Active Users" and close that user.

Second thing to try:

In the above test, if there are truly no "Active Files" listed, then
that points to one of the DDFs being locked by the OS. If this is a
Windows Server, that can happen. Using the Pervasive Function
Executer, try opening all of the DDFs one after the other. If any of
them are inaccessible, try restarting the server to unlock the file.

HTH

Wayne Freeman
www.analyticabiz.com

To subscribe to our Pervasive News Feed:
www.analyticabiz.com/rss20.php

spark ha scritto: