BTRIEVE 6.15 FOR DOS
qiqo
on Msdos 6.22 with memory manager EMM386 and HIMEM.sys. Problem happened
when i want to stop btrieve with command butil -stop. error message is
EMM386 has detected error #12 in an aplication at memory addres FDC8:4256.
To minimaze the chance of data loss, EMM386 has halted your commputer
Andrzej Włoszczyński
bugs that they are unusable.
--
Andrzej Wloszczynski
HPS S.C.
Warning! remove REMOVEIT from my e-mail address
qiqo
Andrzej Włoszczyński wrote in message ...
>thanks
i have version 6.15.430 by the way where i can find update(i have licence)
Mirtheil
newer than the v6.15.925 engine. What version of BUTIL are you using? you
should use the one that came with the DOS workstaition engine.
Andrzej Włoszczyński
It's
>newer than the v6.15.925 engine.
Are you sure. I have checked the following pages:
http://www.pervasive-sw.com/support/technical/papers/bdupd.html
http://www.pervasive-sw.com/support/technical/papers/dcmatrix.html#BD615
and found the following information about the newest Btrieve for DOS
version:
Btrieve for DOS v6.15.925 (Released, October 1995)
File Version Release date File size
BTRIEVE.EXE 6.15.925 10/10/95 271548
PMSWITCH.EXE 1.03 06/01/95 241716
You can download current patches from the link above.
Mirtheil
released as a patch. Here's the dir of the BTRIEVE.EXE...
BTRIEVE EXE 277,689 10-13-96 2:13p
PMSWITCH EXE 241,716 06-01-95 2:53p
Danny Dion
"Andrzej Włoszczyński" <h...@REMOVEIT.hps.com.pl> wrote:
> >Actually, v6.15.430 is the last version of the DOS workstation engine..
> It's
> >newer than the v6.15.925 engine.
>
> Are you sure. I have checked the following pages:
>
> http://www.pervasive-sw.com/support/technical/papers/bdupd.html
>
> http://www.pervasive-sw.com/support/technical/papers/dcmatrix.html#BD615
>
> and found the following information about the newest Btrieve for DOS
> version:
>
I agree, The newest version of Btrieve Dos is 6.15.925 You can't download the
patche. You must ask to pervasive and give them a proof of your first page
of the manuel and then pervasive should be download the engine.
But it's not very better of earlier version.
1) if you use dos extender in your APP forget it???
2) if you use in a dosbox of win95 good luck???
3) If you have application with overlays good luck again???
4) If your application is an staight Dos environment without DOS EXTENDER
probably that will run OK.
> Btrieve for DOS v6.15.925 (Released, October 1995)
>
> File Version Release date File size
> BTRIEVE.EXE 6.15.925 10/10/95 271548
> PMSWITCH.EXE 1.03 06/01/95 241716
>
> You can download current patches from the link above.
>
> --
> Andrzej Wloszczynski
> HPS S.C.
> Warning! remove REMOVEIT from my e-mail address
>
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Danny Dion
I have That:
BTRIEVE EXE 271,548 10-10-95 3:54p BTRIEVE.EXE
same PMSWITCH.exe
when I start the engine I got:
DOS/4G Protected Mode Run-time Version 1.97
Copyright (c) Rational Systems, Inc. 1990-1994
Protected Mode Switch Program for DOS
Version 1.03
(C) Copyright 1982-1995, Btrieve Technologies, Inc.
All Rights Reserved.
MicroKernel Database Engine v6.15.925
Copyright (c) 1982-1995, Btrieve Technologies, Inc.
All Rights Reserved.
Is it possible to have an older version with an higher version number?
The version that what I see is it only for Micro Kernel version???
In the DOC patches the sequence is: 6.15.321, 6.15.525 and 6.15.925.
So far, It's doesn't matter.
Mirtheil
used to based the revision on a date so, 6.15.925 was from Sept. 25. v6.15.430
was from April 30 of the next year. You can only get v6.15.430 from a new
install or if you have a specific problem addressed by the engine (there were
only a couple of things as far as I know).
Andrzej Włoszczyński
how I can get it. I'm the licensed user of Btrieve Developer Kit and
Btrieve Workstation Engine (Unlimited Distribution License).
--
Andrzej Wloszczynski
HPS S.C.
Warning! remove REMOVEIT from my e-mail address
>Yep.. I'm sure.. The v6.15.430 was only released as a full engine and
mike....@ziplog.com
So seems .. offically now, over this post from you and what we just
went through with tech support...
Andy .. based on your post and a possible problem with PowerBASIC and
Btrieve 6.15.whatever, I just went through a tech support relationshsip
over this whole .430/.925 deal.
I thought, as your original post implied, that the .925 release was
newer than the .430 release. I just learned, officially, grin, that it
is not.
We were involved in a tech support issue back in 1997 over failures
during use of multiple serial ports in DOS-VDM sessions in OS/2 boxes.
As I recall, there was a test version that we had in-house at the time,
and it was followed by a formal release .. for the fix..
At that time, I *THOUGHT* that the formal release was the .925 version.
When the "fix" was distributed the "fix" came to us as a complete CE and
DV deal in two different ZIP files. I downloaded these two files, at
the request of Btrieve from the BBS hard-phone line download. The "fix"
was installed and the problems went away for good. The download date
for that event was 17-Oct-97 per the logs here. I never paid any
attention to the version number in this fix... until ... now...
grin...
Now, as a result of your post and our probing.. that what we got in the
download of 17-Oct-97, was, indeed, version ".430", not the "earlier"
version, ".925" which we had already seen and used and didn't realize
how it fitted into the scheme of things...
grin...
We have a major suite of programs which use 6.15 and have moved most of
the DOS source to PowerBASIC. There are some IDE/debugger problems with
PB which, obliquely, just might be related to Btrieve, or so it has been
intimated. Your post about version .925 being "newer" than .430
provoked a request to try the .925 version, as a "newer" version.
Yep .. Btrieve acted.. they are good folks...
Btrieve did furnish .925 for test here yesterday. They are GOOD people
over there and I'm one of the few that might know that on a personal
basis as it so happens that I'm over in Aggieland at College Station,
Texas, and the are over in Longhorn country in Austin, Texas. That's
only a hundred miles away!
It *IS* possible for an Aggie to milk a Longhorn, but you have to do it
*VERY* carefully.. grin...
The tech support folks noted that ".925" is not the latest release. The
".430" is later, as the file time stamp does indicate. I'm sure they
are either puzzled or chuckling over the confusion between ".925" being
newer than ".430" or whatever..
whatever...
It turns out that ".925" was one of the earlier versions that was
involved, on the way to ".430" as a solution for somethings. It also is
now clear to me that ".430" was the actual release that, in our case,
*DID* make a difference in stabilizing our suite. Too, I'll side with
your comment that, until the ".430" came out, we had a LOT of trouble
keeping things stable, but the stuff has been quite stable since then.
No, ".430" is better than ".925" for us.. I've verified that at this
point... Your mileage may vary; it's a heck of a lot further from you
to Btrieve than us to them! Grin...
As to ".430"...
What we see now is not operational instability in the finished code, but
a quirk in the IDE/debug arena, if, in fact, it is related to Btrieve
in any way. Personally, I have no evidence it is, at all. We're just
tying to cover everything in running it down. Your post prompted a
thought that we should "try" the ".925" version, which, we discover, we
already have passed up in favor of ....
As a paid-for subscriber to Btrieve's products, I've never found them to
not be willing to service a client for that latest normal public version
of 6.15.whatever.. Just a confirming response that ".430" is what
fixed our problems over here and what, I suspect, you may eventually
find you are using, in an ongoing quest to optimize your work with what
has been a fine product for us.
If you approach this Texas Longhorn animal cautiously.. I'll bet you can
get it milked too!
:)
//-----------------------------
Mike....@ziplog.com
Mike....@f3000.n117.z1.fidonet.org
rot...@ibm.net
Thanks, we're trying really hard, so keep on talking to us. We have a
wonderful Director of Debvelopment who is responsible for the SDK who is an
Aggie!
Teh versioning is quite confusing, but basically development used the month
and year to denote versions until 4/30/96 thus giving us
6.15.525 1995
6.15.925 1995
6.15.1208 1995
6.15.430 1996
Then they fixed it giving us
6.15.430 1996
6.15.431 1996
6.15.435 1996
6.15.440 1997
6.15.445 1997
6.15.451 1998
Not all versions were released for each engine so 6.15.430 was the last
workstation engine and 6.15.451 was the last client/server engine for
Btrieve. Pervasive.SQL fixes the versioning issues and a whole lot more.
Check it out on the Web site along with Tango!
Regards,
JohnR
>
>Yep .. Btrieve acted.. they are good folks...
>
>Btrieve did furnish .925 for test here yesterday. They are GOOD people
>over there and I'm one of the few that might know that on a personal
>basis as it so happens that I'm over in Aggieland at College Station,
>Texas, and the are over in Longhorn country in Austin, Texas. That's
>only a hundred miles away!
>
>It *IS* possible for an Aggie to milk a Longhorn, but you have to do it
>*VERY* carefully.. grin...
>
>
> whatever...
>
>What we see now is not operational instability in the finished code, but
>a quirk in the IDE/debug arena, if, in fact, it is related to Btrieve
>in any way. Personally, I have no evidence it is, at all. We're just
>tying to cover everything in running it down. Your post prompted a
>thought that we should "try" the ".925" version, which, we discover, we
>already have passed up in favor of ....
We see a lot of issues that folks think are Btrieve, but really aren't since
Btrieve is so tightly integrated and dependent on many computer subsystems
so this is not unusual. When we find a big we try to fix it fast though.
>
>As a paid-for subscriber to Btrieve's products, I've never found them to
>not be willing to service a client for that latest normal public version
>of 6.15.whatever.. Just a confirming response that ".430" is what
>fixed our problems over here and what, I suspect, you may eventually
>find you are using, in an ongoing quest to optimize your work with what
>has been a fine product for us.
>
Thanks again, it's nice to hear customers say that about us because we
really do try hard.
Regards,
JohnR