We are considering a move from V7 to V8. Our question is, is it
really worth doing? Will the performance tools in the new version
help us with our processing (we have some cycles on our system
(LifePro) that can take 10 hours to process)? Is there much of a
conversion with the databases from v7 to v8? Our databases are quite
large, and we really have to find a way to speed up our processes.

I would appreciate hearing from anyone who has experience with this.

Thanks for all input.

Cynthia Merritt wrote:

Hi,
three questions and the answers are: no, no, no.
(1) Some of our (valid) SELECT statement do not work any more with V8. (2)
In our case, the promised performance boost could be noticed only by adding
timers (it does not matter for an end user if a query returns with 20 or 18
minutes) and (3) it was no problem to 'upgrade'.
I think, performance is much more a question of the database schema than it
is one of the engine version.

Regards
Uwe

P.S. Problem (1) also occurs with 7.94 and the latest 'hot fix'. We had to
remove it from our installations.

Performance may be only one of the items to consider when
contemplating an upgrade.
1A) Does the application vendor support you running their application
on the new version. This could be a real show stopper especially if
as pointed out by the other reply the application does not even
function properly with the new version. Of course if it is a change
of behavior it should be reported so that it can be fixed. See
"Report a product defect" here: http://www.pervasive.com/support/ it
is free.
1B) The flip side question is, does the application vendor have a new
version that explicitly supports the new database.
2) Support for Pervasive.SQL 2000i is coming to an end soon.
http://www.pervasive.com/support/lifecycle.asp

After resolving the questions will it even work and supportability
performance can be addressed.
The performance gains by using Pervasive.SQL V8 varies widely.
Some people see a 10x gain, others see some gain (most common), others
see performance loss. Are any other infrastructure changes planned
for the same time like server OS, server hardware, networking,
application or will this be a straight database engine drop in. Keep
in mind that if you do change more than one item it may be hard to
judge what contributes to any performance changes seen.
e.g. NW 4.11 running 2000i for a 4 hour closing changed to Windows
2003 running V8 for an 8 hour closing on different hardware. I have
heard of it, where would you start? Other things I have seen, going
into an application screen going from 2 second to 62 seconds with a
new database engine with a new version of the application. Found out
that the new version of the application read the entire appointments
file going to the screen to save the user a mouse click (big oops).

The conversion of the data files to the new format to take advantage
of the turbo write accelerator performance feature is optional,
straightforward and recommended. It is just a file rebuild using the
Pervasive rebuild utility.
In fact that would be one of the first steps I would suggest even
before upgrading if performance has been slowly deteriorating over
time. Be sure to select 4096 byte data pages. That step alone can
provide significant performance improvements even with your current
engine.
Have any steps been made to tune the current product?

Leonard

On 14 Apr 2004 08:21:04 -0700, CMerritt (AT) EMCNL (DOT) com (Cynthia Merritt)
wrote:

If you are talking about V7 (i.e.. 7.0, not Pervasive.SQL 2000) and you use
the SQL interface, then the conversion is huge. The whole SQL interface has
been replaced with ODBC (and OLE-DB / ADO) and the SQL syntax is very
different, but much closer to SQL 92 standard. There is no backward
compatibility for the SQL interface.

If you only use the btrieve interface, upgrading is simple, install the new
engine and it will work. You can rebuild your databases if you want to have
access to the new features of V8.

As for performance, some things are faster, some are slower. It might be
wise to install a trial version and put it through it's paces.


"Cynthia Merritt" <CMerritt (AT) EMCNL (DOT) com> wrote