User running newer version of Pervasive than we distribute

[Database Administrator]

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

[Database Administrator]

Joe The Frisbee® schreef:
> 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
>
>

or do a rewrite of your application and use SQLlite
(http://www.sqlite.org/)

--
Luuk

[Database Administrator]

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@goldstarsoftware.com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


Joe The Frisbee® wrote:
> 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
>
>

[Database Administrator]

BtrieveBill 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...

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.

[Database Administrator]

If possible, scan the entire HDD for the presence of WBTRV32.DLL, which
is the primary interface DLL for the 32-bit applications. You should
find one, and you can extract the version from that. If not, go ahead
and install the 6.15 version.

I've helped several organizations make the move to newer engines, and it
really isn't as bad as you might think. (Sometimes it is. ;-) ) You
can let the end users upgrade on their own, which takes all the work out
of it, and we can help with the process. I'd be happy to work with you
to do the same, if it makes sense. Let me know (via EM) if you're
interested in discussing...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@goldstarsoftware.com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


Joe The Frisbee® wrote:
> BtrieveBill 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...
>
> 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.
>
>