 | |
User running newer version of Pervasive than we distribute
comp.databases.btrieve comp.databases.btrieve
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: User running newer version of Pervasive than we distribute -
10-22-2008
, 07:11 AM
|
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. |
#12
| |||
| |||
|
|
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. |
#13
| |||
| |||
|
|
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. |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.