Hi there,

Here a couple of questions I wasn't able to find in the documentation
of Novell and Pervasive. First the system configuration:

A legacy ticketing app under DOS, 10 Windows 98 pc's and a Compaq 3000
server with Novell 5.1. The files the app uses are on VOL1 of the
server. Butil reports Btrieve 5.12.

The system runs fine, but you guess, I want more. I want real-time
data from the database. So, after much reading, I decided Pervasive is
the best option.

I connected a Windows2000 pc with a Novell client and Pervasive
installed to the network. A very nice friend of mine created the three
DDF-files. Demodata is running fine, and when I copy the files from
the server to the W2K pc I can access the data of my legacy app just
fine. Now the questions:

1. When we try to create a database and try to connect to the ddf's on
the server, the database wizard reports something like "cannot connect
to the database. the path may be wrong or the access rights are not
right". I log on to the W2K pc with the same username and password as
the administrator on the Novell server.

What is happening? Does Pervasive use another user to connect to the
database, one that I have to grant rights? Am I making a mistake with
authorizations?

2. To circumvent the problem above, I could copy the files every
minute or so to the W2K machine, and then let Pervasive aquire the
data. But does a copy action have any influence on the working of the
legacy app and/or Btrieve?

3. In case we can connect to the files on the server: I have seen that
if no microkernel is running on the server, Pervasive starts in
Gateway mode, and the first Pervasive server makes a LOC file. But how
does that work together with the legacy app, and Btrieve. Does LOC'ing
the files work together with Btrieve 5.12? Cause I can't have my data
aquisition disturb the normal working of the legacy app.

Well, maybe somebody can shed some light on the above, thanks in
advance.

Jeroen Bakker

The only word that comes to mind right now is ***STOP***. There are many
things in your message that, if what you describe is accurate, can lead to
major problems or data corruption for the application. I hope you are
working on this in a test mode only, and NOT in a production environment!

Let's list the "don'ts" first, then we'll discuss a solution.
- Don't copy files while they are in use on the primary server. The
resulting access conflicts can cause problems in the production
environment, and if the files are already open and being modified on the
source server, they will possibly be corrupted on the target. A good way
to tell is if the target database engine is reporting "SYSTEM ERROR" in
the PVSW.LOG file.
- Don't access remote data files with a local engine. If the gateway does
indeed go active on the Win2K box, this will potentially lock out users on
the NetWare side and cause no end to the problems, including Status 85,
Status 46, and a myriad of other possible problems.


Having said that, let's look at what other information we need.
- First, which version of the Pervasive database is running on the
server? BUTIL is a DOS-based utility, and is NOT related to the database
version. Many applications have their own BUTIL.EXE in the app directory,
and this has no bearing on the database in use. To check this on NetWare,
use the command "MODULES NWMKDE*" on the server and see which version is
returned. Additionally, check the version of the SRDE with this command
"MODULES NWSQLMGR*". If this returns no data, then you don't have the SQL
engine running on the server, and we need to know this as well.
- Second, if you are running Pervasive.SQL 2000i (which comes on NW5.1 by
default), have you installed a valid user count to the database server?
NetWare comes with a 2-user permanent license and an Unlimited-User 90-day
license only for this database.
- Third, which module are you loading in DOS to access your database on
NetWare from the application? This should either be "BTRIEVE.EXE",
"BREQUEST.EXE", or "BDOSSTUB.EXE" and should be clearly visible in your
BAT file that launches the application. Additionally, what version of
this EXE is being reported? This will tell us a lot more about HOW you
are accessing the database.
- Fourth, you mention that your Win2K box has "Pervasive installed" --
what does this mean? Did you install only the Pervasive.SQL 2000i client
from the PVSW\CLIENTS directory on the server? Did you install a
Pervasive.SQL 2000i workstation engine? Did you install Pervasive.SQL V8
Workgroup Engine? Did you install a PSQL2000i or PSQLV8 Client/Server
Engine? Please be more specific here, as this will drastically change the
possible solutions and advice.
- Fifth, are there database paths located inside the DDF's that your
friend created? You can check this by starting the PCC/SQL Data Manager
window and either double-clicking on the X$File table or issuing the SQL
statement: SELECT * FROM "X$File" If you see pathnames in the Xf$Loc
field, then they may need to be removed to work correctly.

Let's start there, and the answers from these questions will help
determine which direction to go next...
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: June, 2004: See our web site for details!


Jeroen Bakker wrote:

Bill,

Thank you for the already very valuable information you gave. So, no
copying, no local engines. Was afraid that wouldn't work, but had
still a little hope.

Furthermore, as you guessed, it is a complete testing environment. No
fooling around with the existing situation, just a testserver with
back-upped data.

Now the answers to your questions:
1. MODULES NWMKDE* returns:
NWMKDE.NLM v7.51.001
Version 7.51 20 september 1999

MODULES NWSQLMGR* returns nothing, although when I cycle through the
Novell screens I do see SQLMON running, reporting 0 engines.

2. I have performed a clean Novell 5.1. server installation, so I
presume I'm still in the 90 day eval period (on the server). I do not
have problems aquiring a license, if that helps me solve the problem,
but first I want to know if it works.

3. I'm loading BTRIEVE.EXE on the local Windows98 machines, which
report:
Btrieve /N Record Manager Version 5.10a

4. The Pervasive information on the W2K machine. That was harder,
which I hadn't expected : ) But starting the install again reported:
Pervasive SQL 2000i
Server for Windows Update
I also have seen:
Pervasive. SQL 2000i SP4
Currently there are two services running on the W2K machine:
Pervasive.SQL 2000 (relational)
Pervasive.SQL 2000 (transactional)

5. I checked the DDF's, and there were no paths included in the Xf$Loc

I also checked the PVSW.LOG and the only errors reported were from
when we tried to connect to the files on the server, reporting
8505/8517 errors.

Thanks in advance, Jeroen


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

This spells trouble all-right and you've been very lucky sofar....

The 90 day eval is not enabled by default, so if you didn't apply any
licenses yourself you'll most likely be on the default 2. Check with
"LOAD NWUCUTIL -G11" if you want to be sure.

SQLMON is not part of Pervasive.SQL; could be from a Sybase or
Allbase/SQL install.

In a default NetWare install, Btrieve and related components may be
autoloaded by the OS. In most cases this will not include the
communication modules BSPXCOM and BTCPCOM that are needed to grant
remote client access. One or both of the communication modules may get
loaded by server software such as Arcserve. Currently I do not know of
any NetWare server software that relies on Pervasive relational
engine, so you should not find NWSQLMGR unless you specifically added
a load command for it (MGRSTART.NCF).

Your luck starts where you installed the client/server version of
Pervasive.SQL on your Win2k box as this engine will only load files
from the local machine. This prevented you from accessing the files on
the NetWare server through the relational interface.

If you didn't try already, I'd also suggest you don't try to run the
original application from your Win2k box either. The Pervasive.SQL
install will prevent Btrieve.exe to load and attempt to set up a
Pervasive client-server connection. If it succeeds in doing so you
will either be confronted with locking issues yourself or lock out
everyone else. The worst will happen if updates are in progress which
could leave your database beyond repair.

Note that at some point in time you will have to retire the old
Btrieve.exe, simply because you'll run into a pile of problems when
you try to run it on any newer machine running Win2k or XP. You should
therefore verify it can run with Pervasive.SQL, just don't do it on
your live data! And that means never; not even when nobody else is
using it.


On 24 May 2004 04:22:04 -0700, baxbakker (AT) hotmail (DOT) com (Jeroen Bakker)
wrote:


Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/

Gordon,

Thank you for your information, although it isn't what I hoped for ;(

One lucky thing, next year we're going the use the upgrade, which offers a
choice of 'normal' databases, which I make sure will be more accessible.

But that doesn't solve my problem for this year. I'm running out of options,
while the data still sits on the server and is wanting to be used! Could it
be that the only option is to get somebody to read the data live from the
legacy app and have him or her type it in the information display program?
With the amount of data I need it is an option, but it makes me sad.

Resuming:
- a Novell 5.1 server that acts as a fileserver for the legacy app;
- 10 windows 98 clients with a legacy app under DOS using Btrieve 5.10a;
Results in:
1: don't use copying, it can result in access violations;
2: don't use a local engine on any client, it will lock the database;
3: better still, don't use Btrieve on a W2K client with Pervasive installed;

Ai, all those don'ts were my options.

I'm not knowledgeable enough on Btrieve 5.10a, but is it an option I get a
programmer with Btrieve experience to write an acquistion interface on the
existing files, using Btrieve as a requester? Is this done before, and what
are the implications on the legacy app if we try that?

Are there other options?

Thank you in advance, Jeroen



Gordon wrote:

Coming to this later than the other posters.

Jeroen Bakker wrote:

So, an old version of Btrieve on a Netware server.

Indeed. We're moving from DOS/Btrieve to Windows/Pervasive.SQL

So, local access on a PC to the files via a database and DDFs works. This
is good to know as it means the data in the btrieve files can be mapped
to Pervasive SQL.

Now the questions:
Btrieve 5.12 does not support databases and SQL access.

Not ideal as you cannot be sure that when the files are being copied
they are not also being updates.

I suspect this is because you have a very old version of Btrieve on
the server.

We're currently running DOS apps which are linked with a Btrieve 6.15
client library against a Netware 5.1 server running Pervasive SQL 200i.

We're soon to upgrade to Pervasive SQL V8.5.

Currently our Windows PCs have the Pervasive SQL 2000i client installed
on them and they support both new Windows programs accessing data via
Pervasive SQL 2000i and DOS programs accessing the same data via Btrieve.

Given the upgrade costs for a 10 user Pervasive SQL V8.5 license is not
that great I think this is an option to consider.

Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk

Guy,

Thank you for your insighfull ansers. Your option, migrating to a newer
version, isn't one I dare to undertake, unfortunately. I do not have the
support of the vendor, and time is to short to test the app good enough by
myself (I also don't have the knowledge for that). Production comes first,
and acquiring data is just a nice to have (although a very handy one). The
only option I'm wiling to take is where my current configuration will not
change, only non-intrusive data acquistion is allowed. And that seems not
possible, reading the other answers on the newsgroup.

Thank you for your time, Jeroen

Guy Dawson wrote:

Just to fill in the blanks:

1) Btrieve 5.10a is a client engine (or local engine if you wish) that
opens your datafiles in share mode. This method is known to cause
several kinds of corruption and was therefore dropped after Btrieve
6.15.

2) The new Pervasive.SQL engines will request exclusive access to the
datafiles. To grant other users access to the data a Pervasive.SQL V8
workstation engine (workgroup engine on PSQL 2000) can act as a
(Btrieve) server engine to other Pervasive.SQL workstation engines

3) As of Btrieve 6.x the way Btrieve (or microkernel) accesses
datafiles has changed. The newer file formats have no need for
pre-image files and although any newer engine will still use them on
pre version 6 data files they are handled differently from the way
Btrieve 5.10a does.

Using both a Btrieve 5.10a and a Pervasive.SQL engine on the same data
will either lock one of the two engines out (1+2) or could very
possibly lead to file corruption (3).

Given the fact that there's no ODBC on Btrieve 5.10a your best option
is to make a full switch to Pervasive.SQL. Obviously this means you
will have to verify that you can run the application using a
Pervasive.SQL client instead of Btrieve.exe. In most cases this should
not be an issue and just about anything else is easy enough to solve.
As far as Btrieve is concerned this will also enable you to migrate
the application to Windows 2000 and XP platforms.


On Tue, 25 May 2004 16:42:44 +0000, Jeroen Bakker
<baxbakker (AT) hotmail (DOT) com> wrote:


Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/