I'm that dinosaur in here who still uses and distributes Btrieve 6.15 since
we bought an unlimited distribution license, and it works. We realize that
one day (maybe today?) we're going to HAVE to upgrade to the current
release. While this is free for us as the developers (in the sense of the
SDK) what's holding us back is the cost to the end-users, and because of the
current economic crunch, we can't absorb that cost ourselves (even at only
$25/seat).

We have a client that has another Btrieve application, is more a power-user
type, and is running a current (v 10?) Pervasive. When he tries to run our
6.15 Btrieve app, it's behaving strangely. It seems to be able to read data
fine, but is having trouble writing data and also with transaction logging
(begin tran). Strangely enough, it must have been able to write data at
some point because the data conversion (from 5.10a DOS to 6.15 Windows
format) worked okay, however the system is never able to log him out
(updating a simple file) and gets errors anytime our code tries to begin
transaction (opcode 19 or 219). Also, there appear to be times when he can
add records, with no errors, but the records are not there?

Is there a known problem with the current or recent versions of Pervasive
working with older applications such as mine compiled (VB 6.0) with 6.15
Btrieve? Am I going to have to upgrade?

Any feedback appreciated.

Bill "Frisbee" Hileman, CPD

Joe The Frisbee® schreef:
or do a rewrite of your application and use SQLlite
(http://www.sqlite.org/)

--
Luuk

Joe The Frisbee® schreef:
or do a rewrite of your application and use SQLlite
(http://www.sqlite.org/)

--
Luuk

Joe The Frisbee® schreef:
or do a rewrite of your application and use SQLlite
(http://www.sqlite.org/)

--
Luuk

Your 6.15 application should work fine, with a few caveats:
1) Make sure that you are reporting ALL errors coming back from the
Btrieve calls, especially on Inserts, Updates, and Deletes. Many
developers only handle the "obvious" errors and any unusual error may be
skipped and never reported. The easiest way to do this is to create a
new function (say, EBTRV) that encapsulates your current call to the
database (BTRV) which ALSO logs (to screen or a log file) any non-zero
status codes that come back. You can also add some debugging code that
can be switched on or off inside the same call. Then, change your calls
from BTRV to EBTRV where you ONLY expect a 0 status code to come back,
and you'll have good error logging.

2) Check (with BUTIL -STAT) for any files that are in the 5.x format.
If you have some older 5.x files, the PSQLv10 engine will NOT write to
them (returning Status 46). Rebuilding the files to at least 6.x format
will resolve this issue.

There may be more, as well, but knowing the status codes is the FIRST
issue...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


Joe The Frisbee® wrote:

Your 6.15 application should work fine, with a few caveats:
1) Make sure that you are reporting ALL errors coming back from the
Btrieve calls, especially on Inserts, Updates, and Deletes. Many
developers only handle the "obvious" errors and any unusual error may be
skipped and never reported. The easiest way to do this is to create a
new function (say, EBTRV) that encapsulates your current call to the
database (BTRV) which ALSO logs (to screen or a log file) any non-zero
status codes that come back. You can also add some debugging code that
can be switched on or off inside the same call. Then, change your calls
from BTRV to EBTRV where you ONLY expect a 0 status code to come back,
and you'll have good error logging.

2) Check (with BUTIL -STAT) for any files that are in the 5.x format.
If you have some older 5.x files, the PSQLv10 engine will NOT write to
them (returning Status 46). Rebuilding the files to at least 6.x format
will resolve this issue.

There may be more, as well, but knowing the status codes is the FIRST
issue...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


Joe The Frisbee® wrote:

Your 6.15 application should work fine, with a few caveats:
1) Make sure that you are reporting ALL errors coming back from the
Btrieve calls, especially on Inserts, Updates, and Deletes. Many
developers only handle the "obvious" errors and any unusual error may be
skipped and never reported. The easiest way to do this is to create a
new function (say, EBTRV) that encapsulates your current call to the
database (BTRV) which ALSO logs (to screen or a log file) any non-zero
status codes that come back. You can also add some debugging code that
can be switched on or off inside the same call. Then, change your calls
from BTRV to EBTRV where you ONLY expect a 0 status code to come back,
and you'll have good error logging.

2) Check (with BUTIL -STAT) for any files that are in the 5.x format.
If you have some older 5.x files, the PSQLv10 engine will NOT write to
them (returning Status 46). Rebuilding the files to at least 6.x format
will resolve this issue.

There may be more, as well, but knowing the status codes is the FIRST
issue...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


Joe The Frisbee® wrote:

BtrieveBill wrote:
I appreciate the suggestions, Bill.

After reading the white paper specifically written on upgrading from 6.15 to
v 10 I got the impression that my software -should- indeed run seamlessly
under v 10 and apparently I was right.

I downloaded and installed the trial version and my software ran flawlessly
(as a compiled app) but I discovered I was no longer able to run it in the
development environment (VB 6). This had happened to me five years ago,
too, when I downloaded a trial of v 8, had to re-install Btrieve and
Smithware (ActiveX controls) after uninstalling. I had hope that I might
not have to, since I noticed during the install that it was "looking for
legacy software" beforehand and "archiving" so I thought it might actually
restore back when uninstalled. Crap.

I used v 10 while it was installed to check out the system with my existing
6.x level data, and it worked fine. I then re-converted old DOS 5.x data
under v10 and that likewise worked flawlessly, so I came to the conclusion
that it must be either somehow their data was at 5.x (which my status calls
said were 6.x) or more likely, my 6.15 btrieve install over-wrote and
corrupted their pre-existing v10 system from a third-party product.

Since Pervasive did not use versioning in their early releases, I know of no
way to determine that my end-users have a more recent version of Btrieve
running on their system, so I've had to make the Btrieve a component option
(Using Inno Setup) and not modify registry entries or install components if
not checked. I would prefer to have some way to determine what version, if
any, an end-user has already installed on their system. Are you aware of
any tricks to accomplish that?

Anyway, I've made the component option available in my setup, and told the
end-user to re-install his program management software (the other app that's
running v10) and see if our app behaves once again, and informed him of the
change in our install to prevent it happening again.

I called Pervasive about the possibility of once again having to bite the
bullet and upgrade to v10, but was disappointed to learn that the per seat
licensing fee has gone up a bit (from $25 to $49). Because of the current
economic crunch, our small (2-man) software house cannot absorb that cost
for potentially hundreds of users.

BTW, are you hiring? :-)

I just realized I've been using Pervasive products for over 23 years now,
sheesh.

BtrieveBill wrote:
I appreciate the suggestions, Bill.

After reading the white paper specifically written on upgrading from 6.15 to
v 10 I got the impression that my software -should- indeed run seamlessly
under v 10 and apparently I was right.

I downloaded and installed the trial version and my software ran flawlessly
(as a compiled app) but I discovered I was no longer able to run it in the
development environment (VB 6). This had happened to me five years ago,
too, when I downloaded a trial of v 8, had to re-install Btrieve and
Smithware (ActiveX controls) after uninstalling. I had hope that I might
not have to, since I noticed during the install that it was "looking for
legacy software" beforehand and "archiving" so I thought it might actually
restore back when uninstalled. Crap.

I used v 10 while it was installed to check out the system with my existing
6.x level data, and it worked fine. I then re-converted old DOS 5.x data
under v10 and that likewise worked flawlessly, so I came to the conclusion
that it must be either somehow their data was at 5.x (which my status calls
said were 6.x) or more likely, my 6.15 btrieve install over-wrote and
corrupted their pre-existing v10 system from a third-party product.

Since Pervasive did not use versioning in their early releases, I know of no
way to determine that my end-users have a more recent version of Btrieve
running on their system, so I've had to make the Btrieve a component option
(Using Inno Setup) and not modify registry entries or install components if
not checked. I would prefer to have some way to determine what version, if
any, an end-user has already installed on their system. Are you aware of
any tricks to accomplish that?

Anyway, I've made the component option available in my setup, and told the
end-user to re-install his program management software (the other app that's
running v10) and see if our app behaves once again, and informed him of the
change in our install to prevent it happening again.

I called Pervasive about the possibility of once again having to bite the
bullet and upgrade to v10, but was disappointed to learn that the per seat
licensing fee has gone up a bit (from $25 to $49). Because of the current
economic crunch, our small (2-man) software house cannot absorb that cost
for potentially hundreds of users.

BTW, are you hiring? :-)

I just realized I've been using Pervasive products for over 23 years now,
sheesh.

BtrieveBill wrote:
I appreciate the suggestions, Bill.

After reading the white paper specifically written on upgrading from 6.15 to
v 10 I got the impression that my software -should- indeed run seamlessly
under v 10 and apparently I was right.

I downloaded and installed the trial version and my software ran flawlessly
(as a compiled app) but I discovered I was no longer able to run it in the
development environment (VB 6). This had happened to me five years ago,
too, when I downloaded a trial of v 8, had to re-install Btrieve and
Smithware (ActiveX controls) after uninstalling. I had hope that I might
not have to, since I noticed during the install that it was "looking for
legacy software" beforehand and "archiving" so I thought it might actually
restore back when uninstalled. Crap.

I used v 10 while it was installed to check out the system with my existing
6.x level data, and it worked fine. I then re-converted old DOS 5.x data
under v10 and that likewise worked flawlessly, so I came to the conclusion
that it must be either somehow their data was at 5.x (which my status calls
said were 6.x) or more likely, my 6.15 btrieve install over-wrote and
corrupted their pre-existing v10 system from a third-party product.

Since Pervasive did not use versioning in their early releases, I know of no
way to determine that my end-users have a more recent version of Btrieve
running on their system, so I've had to make the Btrieve a component option
(Using Inno Setup) and not modify registry entries or install components if
not checked. I would prefer to have some way to determine what version, if
any, an end-user has already installed on their system. Are you aware of
any tricks to accomplish that?

Anyway, I've made the component option available in my setup, and told the
end-user to re-install his program management software (the other app that's
running v10) and see if our app behaves once again, and informed him of the
change in our install to prevent it happening again.

I called Pervasive about the possibility of once again having to bite the
bullet and upgrade to v10, but was disappointed to learn that the per seat
licensing fee has gone up a bit (from $25 to $49). Because of the current
economic crunch, our small (2-man) software house cannot absorb that cost
for potentially hundreds of users.

BTW, are you hiring? :-)

I just realized I've been using Pervasive products for over 23 years now,
sheesh.