We have an unlimited distribution license for the Win 95/NT version of
Btrieve for Windows 6.15. We've been using this for many years, and
continue to distribute it with our Windows applications.

Through various research, and trial and error, I had determined the files
that needed to be distributed to the end-users, as the documentation that
came with the package does not seem to cover this issue much, if at all. I
do seem to recall, however, that we were not supposed to distribute the
Microkernel Setup program, and had been distributing a pre-defined BTI.INI
instead. Various problems with settings over the years, and new flavors of
operating systems have caused setup issues with various clients. Are we
indeed forbidden to distribute the MK setup program? Could I modify my
installation package to actually run the original Btrieve installation setup
program itself, which would install Btrieve along with the MK setup?
There's very little documentation on the BTI.INI file, as well, which has
also proved quite frustrating.

I realize the "best" solution is to upgrade users to v8, but even at
$25/seat, this could be quite an undertaking with our client base, and we'd
pretty much have to bear the financial burden on the upgrade.

Does anyone have any decent docs on file distribution/MK setup for 6.15?
Bill Bach? Others?

--
Bill Hileman, MCP, CPD, BCIP
Programmer/Analyst, DASI

http://www.dasi-software.com
http://www.bailbondprogram.com

The UDL license agreement specifically states:
"...Pervasive grants Company a nonexclusive, nontransferable license to combine
Object Code with Company Products to create Derivative Software Products."

In Exhibit A, the definition of "Object Code Materials" is provided, and it
clearly includes all of the related files, including W32MKSET and its related
DLL's & EXE's. As such, there is nothing prohibiting you from distributing
these files needed for the proper configuration of the database -- and I
encourage you to do so for completeness' sake. As for including the setup
program, I have seen people do this, also for the sake of completeness, since it
is the easiest way to distribute the "object code materials" in their original
form.

By the way -- the Win95/NT version does NOT use the BTI.INI file for its
configuration settings -- this is ONLY used for Win16 applications, and does not
impact the Win32 engine. All the settings for the Win32 engine are in the
Registry, instead.

BTW, I've worked with other developers migrating to Pervasive.SQL V8 from 6.15,
in both the financial and medical industries. This is not as hard as it seems,
and we can help you bring them up to V8 if you wish. Most companies put the
burden of the upgrade onto the end user, but the performance gains and improved
stability are WELL worth the upgrade costs, especially to smaller sites (under 5
users). I'd be happy to talk with you further about doing this for your
customers, as well.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: June, 2004: See our web site for details!



Frisbee® wrote:

Bill Bach wrote:
Thanks for clearing that up. I noticed that the Setup.Exe that comes with
the package appears to be InstallShield (a very old version, I'm sure). I
use Wise InstallBuilder, myself (also a very old version). Is there a
command line switch I can pass, like /s or /q to have it perform a silent or
quiet install, much like when I install Microsoft's Agent stuff?

Well that explains why when I make my changes, my local BTI.INI never gets
updated (duh). I had been distributing a "standard" BTI.INI when one of my
Windows apps was compiled under VB 3.0 (16-bit). That app is now 32-bit VB
6.0, as are my other apps, but I didn't realize I didn't need the BTI.INI
anymore. Is there some way to have my apps installed with pre-defined
settings without having to require the end-user to go through the 32-bit
setup themselves? I would imagine, then, that I'd need to set various
registry entries myself? I could do this with Wise if I knew where to set
them, obviously AFTER Btrieve itself had been installed.

We beta-tested the v8 and were pleased with the performance overall. Quite
a jump from 6.15. My boss noted that there was quite a bit of slowness over
the network, however, but on my local machine it was lightning fast. I know
that Pervasive addressed the network i/o issue by implementing caching. I'm
pretty sure we tested it again after that change and did notice an
improvement, but for obvious reasons the first bits of file i/o were still
slow, but then the later accesses were significantly faster. I also very
much liked how it interfaced with our legacy DOS applications without having
to mess with the hoops you used to have to jump through. All we had to do
was stop loading the DOS version of Btrieve (5.10a) and it worked without
change.

It isn't the technical aspect of upgrading to v8, it's merely that we
haven't bitten the bullet and committed to eating $25/seat for all our
end-users. Unfortunately for me, it really needs to be pretty much
all-or-nothing since my development machine does not like 6.15 co-existing
with v8 at all. I really want to upgrade, however it would force all my
end-users to do so as well, so for now, I'm working with very old ActiveX
controls (the old Smithware absorbed by Pervasive) and an old Btrieve (even
though it still works like a tank).

I'll be modifying my distribution packages to install the complete Btrieve
6.15 for now. Thanks so much for your input.

--
Bill Hileman, MCP, CPD, BCIP
Programmer/Analyst, DASI

http://www.dasi-software.com
http://www.bailbondprogram.com

Frisbee® wrote:

I'm not aware of a silent install. If you want to repackage it, I'd just do a
plain-jane install, then see where the files get put, and duplicate it in Wise.

Yes -- the installer should be able to set the registry settings if you elect to
repackage it. If not, you can export your existing registry (keeping in mind
that RegEdit files can be OS-version-dependent) and re-import it during the
install. This can be done with the "REGEDIT /S filename.reg" command.

Slowness is relative, of course. There's no way to compete with the performance
of the local engine, since network access will ALWAYS be slower. However, the
increase in STABILITY is the real saving grace here. The newer engines are MANY
TIMES more stable, especially on newer OSes, and the results of a computer crash
will rarely (if ever) trash a data file like the 5.x or 6.15 workstation engines
can do.

Don't sell short the idea that the customer can (and will) foot the bill. My
experience is that if sites are experiencing file corruption due to network
failures or WS crashes, they will first blame you and your software. However,
if you let them know that they can individually upgrade to a more stable
database for a relatively low cost (certainly cheaper than the downtime required
for rebuilding files every week), then they will do it, and they will be quite
happy afterwards!

Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: June, 2004: See our web site for details!