Ok, its taken me 2 months to get a Novell 4.11 sp9 server
setup for my evalution for the big upgrade, but now I'm
having second thoughts from doing the upgrade from
btrieve 6.15 to Pervasive 2000 or V8.

And no I'm not being biased, I am the primary developer of
this system an I am not pleased.

My reasons for not even considering V8:

Netware install:
In nowhere in the readme files does it say to copy the unicode files
from the netware 5 support pack to the netware 4.11 directory. I
suppose its just an oversight. That was about 2 hours of my time
searching for the solution. This scares me because I don't want to
be going wacko with the file patching and hope it works due to its
unannounced issue in either the readme or any of the documentation.

Client install:
Once that was done, I tried the client install. It hosed my
local install of Pervasive 2000 on another boot partition of
my local machine for no reason, even though I chose the netware
install. There seemed to be no way to stop that.

My Pervasive 2.04 driver was hosed at this point, so I couldn't
do work on the current system. I'm not sure why it did this, but
sure fine...

The btrieve requester was by default ran some cache service which
I renamed so it wouldn't start up. It also couldn't do a straight
butil -stat on a table like my dos box did until I spent another
hour trying to configure the local requester to stop trying to
run the local engine.

Control Center:
Completely unusable until I spent another hour and a half
researching that the install did not add MGRSTART or LOAD SPXS to
the AUTOEXEC.NCF, so I added those, along with turning off TCP/IP.
I'm not sure why it loaded TCP/IP when TCP/IP service wasn't
configured at all.

So, I get to looking at how it uses the DDF files through the
control center, and I find that I would have to spend an entire
week splitting the ddf file out, along with creating scripts
for over 200 files due to the fact that there is more than one
server involved with the same set of DDFs. And the script
generator I downloaded makes unusable scripts:
I tried one, and it took 3 hours to figure out why it was broken.

And then I find out that I would even have to spend weeks
updating the DDFs anyways, since apparently mapped paths don't
work for the thing.

BTRMON:
Wonderful, no more, staff have no way of monitoring the server
without having to use a windows box.

Well, at least XTRIEVE worked. But ODBC is now hosed.

I'm going to uninstall V8 tomorrow and try 2000. It it
exhibits the same behavior I have no choice but to remove my
approval of the upgrade and use the money for something else.

Ecator wrote:

You are actually UPGRADING to 4.11??? This is an old OS, that I think
even Novell has given up on by now -- you should have at least NetWare
4.2 (which is the minimum OS required as stated on the PSQLV8 box).
Even the README file indicates that they only tested on NW4.2 SP9. A
better solution would be NetWare 6.5, methinks, or at least NW5. Of
course, you can always switch to WinNT, Win2000, Win2003, or Linux. I
have some clients who are VERY happy on Redhat.

The Pervasive.SQL V8 client install is a client install -- not the
server install, so I do not know what you mean about a NetWare install
in this context. Since Pervasive.SQL V8 is a newer version of
Pervasive.SQL 2000, and since there is no need to have both versions on
the same system, the installer does indeed search out any old components
and archives them to the PVSWARCH directory. You can use the PSA to
unarchive the files as needed, but running PSQLV8 and PSQL2000 on the
same system is NOT possible. You should use the newer client, which has
been tested to the older PSQL2000 engine.

The V2.04 driver is a Btrieve 6.15 ODBC driver. This has not been
supported for some time, and is NOT directly compatible with the SQL
engine of Pervasive.SQL V8 (the SRDE). As mentioned above, the
installer automatically searches out all of the old components that
people leave on their system (and usually cause lots of headaches and
other problems), and it archives them to the PVSWARCH directory.

Not just some cache service -- the Cache Engine, a new part of the
client. Why didn't you want the Cache Engine running? There are indeed
some applications that have problems with this performance-boosting
feature, and Pervasive should have these issues addressed in the next
SP. The proper way to disable it, as described in the manual, it to use
the PCC and set "Use Cache Engine" to OFF. What you did sounds a bit
like cutting your spark plug line to keep someone from stealing your
car, then wondering why the car doesn't go any more...

SPXS is only needed if you are running SPX still. About 90% of my
NetWare customers are running TCP/IP, in order to get the absolute BEST
performance. SPX is much slower, and even Novell is trying to kill off
this old proprietary technology.

TCP is enabled in the database by default. In NetWare, when a service
isn't loaded but is used, it can be autoloaded by the OS. This is
probably what is happening in your case. Since the system uses both TCP
by default, it tries to ensure that it is loaded.

As for MGRSTART, this is a definite issue with the install docs. It is
mentioned in Chapter 2 of the Users Guide, but it really should be in
the Getting Started Guide in the section on installation. I thought,
though, that the last time I did an install, it mentioned adding
MGRSTART in one of the pop-up dialogs that came up during the install
itself. I'll have to check this. In any event, it should ALSO be in
the Getting Started Guide, and I've reported this to the folks at
Pervasive so that they can address it.

Didn't see the multiple server thing coming -- does this mean that there
are TWO upgrades to NW4.11 going on here? It is correct that the SRDE
is only happy if all files from a set of DDF's is on the same server.
This is a serious limitation for really big sites with old servers of
limited capacity. However, most people take the upgrade opportunity to
build a faster, bigger server and consolodate licenses where possible.
Collapsing three 100-user servers into a single Unlimited-User server
can save thousands of dollars, and it eases maintenance as well -- or at
least it has for some of my customers, anyway. I have one site with
90GB+ of data on a single box and over a thousand user sessions -- and
the system runs quite well!

If you cannot consolodate servers, then you can always simply make a
copy of the DDF's onto each server and access each one separately, but
this WILL be more difficuly, I agree.

Mapped drives are also regrettably no longer supported, and futher
solidifies the trend towards server-based computing (which have no
mapped drives) and away from client-based computing (which did).
Removing the paths won't take weeks, though. My UPDTTABL utility can
strip out the paths in a matter of seconds (minutes if you include the
time to read the readme and type the command line), and you can provide
the paths as part of the Database Name instead of the DDF's. This will
NOT work if your app reads the DDF for location information though, but
you can always have a duplicate set with the right data in it.

I also lamented the loss of BTRMON, but this was only a problem at sites
which had NO Windows boxes in their server room. In practice, this is
less of an issue, because you can now monitor a server remotely --
without having to access the server and risk a crash with an errant
command. As such, the extra benefits of the GUI-based utility are
evident when you get a large system in place and you have restricted
access to the server console.

What's more, with the DTI/DTO interfaces, there's nothing stopping you
from writing your own utilities to do what you need. I have a customer
in FL who wrote his own NLM to help maintain the server, and I've
written several DTI utilities that work from ANYWHERE on the network,
even from a web server. Imagine the ease of monitoring when you can
watch what's going on from a browser anywhere in the world!

Ahhh, Xtrieve. I have a few customers still using this ancient beast.
It DOES work on PSQLV8, but it is much less forgiving than the SQL Data
Manager. However, if you really like to work in a user interface-based
application (as opposed to a SQL command-based application), then it
still works. Just don't try to use any of the new data types added with
Btrieve 6.x and above, as Xtrieve will not display them correctly.
Also, avoid accessing LARGE DDF's (350+ tables), as Xtrieve corrupts
memory and can trash the DDF's. Also, don't create more than 24 key
segments on a file (even though you've been able to do so since Btrieve
6.15), as Xtrieve will choke on that, too. And don't use True Null
Support (more important for a real SQL developer), as Xtrieve will choke
on them, too. Otherwise, Xtrieve remains a perfectly usable tool. As a
replacement, I'd suggest Gil Nelson's product, BTSearch.

As mentioned above, there are newer ODBC drivers that are vastly
improved over the old stuff. Simply recreate the ODBC DSNs with the new
drivers (and cleaned up DDF's, if needed). The new drivers will run
MANY TIMES faster than the old ones.

PSQL2000 has a similar installer, a similar SRDE, a similar ODBC driver,
and similar DDF restrictions. The only thing it has that PSQLV8 does
not have is more bugs and some performance penalties. Stick with PSQLV8
for the best performance and stability.

On the other hand, Microsoft SQLServer may also be a viable option for
you...
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: September 16-18: See our web site for details!

On 04 Aug 2003 22:23:29 GMT, Bill Bach <bbach (AT) cncdsl (DOT) com> wrote:

<snip>
On a Novell 4.11 box???


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

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

<snip>

Well, thanks guys for your input, but the target date that this has to
be running is like September and well due to the dropped features, I
may have to decline. Its too much a waste of money now that I've
reengineered most of the system to use SQL Server. The server that
did crash last year due to btrieve has already phased out for this new
year.

And no, there is no money to upgrade servers, only the upgraded
licenses, so if it seems pointless to install it on Netware 4.11 over
a multi-tier server environment using SPX, then there is no point in
me approving it.

By the way, Novell 4.2 SP9 is exactly the same as Novell 4.11 SP9, I
believe at SP6 they called it Novell 4.2. However, a base install of
NW 4.2 SP9 will not run pervasive 2000 or V8 period without
modifications as far as I can see.

At this point I'd rather not have any btrieve tables at all and just
fully move to MSSQL 7 or 2000 at this point because its easier to
program to. We have a very large SQL Server 7 cluster that works just
fine, but I just don't have the time to do it all for the moment. I
mean, if I had time to work with the ddfs and modify them, I'd rather
just take their definitions and move them to SQL.

Oh and by the way, I did the install from a dual boot WinXP / Win2k,
where XP was used.

Just wanted to post another item, its my final one.

I did get a temp license for 2000, since the demo cd expired, and
tried it again on my XP Pro box. So I got all the hurdles over and
installed the client software to at least try it the way asked.

The UPDTTABL does not work on the older Xtrieve built files, as the
only way I could actually read a table was to make it from scratch.
There was some flag of 64 in the attrib line that wasn't in these
older .tbl files which I can't edit. Just comes up with 'no such
table or object -1035 and exits.

Every operation, such as add a table, took forever to actually pop up.

So I'm just going to review the facts I have and make my decision.

I do appreciate the input, but I've got other things to do now.

Gordon <grafzerk (AT) bigfoot (DOT) no.spam.please.com> wrote


To note: I've made my decision and its no on the upgrade. The issues that
would be fixed by upgrading would not be resolved unless thing that are
out of my control were performed.

<snip>

Its due to the configuration, normally we have a file-server, btrieve
server and print server, but the print server was consolidated into
the btrieve server in question.

<snip>
Budgets are budgets, I don't make budget decisions. I don't make
hardware decisions. I don't make software decisions. I just give
suggestions.

<snip>

Either way, all the hotfixes were on and every server has the same
set of patches. My dev system is running 4.2 with the extra SP9.

<snip>

Eh, okay, I'm not sure what you mean. I'll take it as comedy

<snip>

I was hoping if this worked that I could at least have a good feeling
about the upgrade, but it wouldn't work. The table would only open if
I recreated it with the SQL Script and not with the UPDTTABL program.
It did cause a different error (#-1035) though.

<snip>

I figured it out, didn't see that you could manually select it the
first time around once it found EVERYTHING. At one point it backed
up the server to my desktop. That, I thought, was funny.

Alls fair in war and databases. I still remember the big thread
war between Windows 95 and OS2 Warp. (I ran OS2 2.1 back then)....