+ Reply to Thread
Results 1 to 5 of 5

User running newer version of Pervasive than we distribute

  1. User running newer version of Pervasive than we distribute

    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



  2. Re: User running newer version of Pervasive than we distribute

    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

  3. Re: User running newer version of Pervasive than we distribute

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


  4. Re: User running newer version of Pervasive than we distribute

    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.



  5. Re: User running newer version of Pervasive than we distribute

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


+ Reply to Thread