Trying to run data base running on btrieve as the underlying record manager. Works file except for 1 file that is 2.8 GB in size. Btrieve can open the file and process some records but other times gets error. I suspect the errors occur when btrieve has to go to an area above 2gb in file. Had same problem with dos box, there couldn't even open the file, and was told problem was a signed integer was used hence then 2gb limit. That shelved the porting project till i discovered vdos. Better since i can at least opn the file but still a fatal problem to futher use. Other wise the old data base system runs good, prints searchs all fine except with the single 2gb file data base problem. Bob Swickle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Btrieve will use DOS 21-42h to set the current file position for the next read or write operation. Registers CX:DX are documented to contain the signed (!) 32-bit offset, so that restricts it to -/+2 GB. Windows API allows for signed 64-bit values, but just interpreting CX:DX as an unsigned 32-bit is no solution: a negative offset can after all be used relative to the current offset or end of file.
It almost seems a bug or limitation of Btrieve. If it would have to position to an absolute position beyond 2GB, it needs to first do an absolute positioning below 2GB, followed by one or more relative positionings until the desired location is reached.
What version of Btrieve do you use? That 2.8GB file comes off a Netware server in combination with Brequest?
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Btrieve is 5.10a network version loaded as a TSR. The 2.8GB file is on a network server, the error coming on a btrieve get record operation. No problem with the 2.8 GB file in pre Windows dos machines and 32 bit Windows XP, 7 & 8.1 systems running under standard cmd.exe dos window. Seems 32 bit Windows systems do something that makes Btrieve happy that vDos does differently.
Bob Swickle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But the 32-bit combined CX:DX registers are documented as a signed offset (http://www.ctyme.com/intr/rb-2799.htm).
Probably there’s an exception for subfunction 0: Move to a position relative to the start of file.
I''l look into how NTVDM proceeds negative offsets with the 3 subfunctions and subsequent read/write operations. I'll report in a few days.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first thing that comes to mind with Btrieve is: Rock-solid reliable database engine.
Essentially all my DOS programming was using Btrieve, though that was more than 15 years ago.
The file structure reported by Butil is correct (4 bytes, AutoInc), but does your programming language support 4 byte unsigned integers. Isn’t it just an interface problem, a 2 byte integer superimposed onto the Btrieve record buffer, misleading you? Can’t imagine a 4 byte auto increment key would wraparound at 65,536. The insert operation would also fail since the key is not unique.
Don’t think there’s a DOS Btrieve forum still around, if there ever was one, Btrieve was a mature specialized tool w/o issues (that I know of).
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It turned out NTVDM treats CX:DX as an unsigned offset with DOS Int 21-4200h (start of file). While it’s considered signed with the other two starting positions.
I changed the vDos interpretation accordingly for the next version.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trying to run data base running on btrieve as the underlying record manager. Works file except for 1 file that is 2.8 GB in size. Btrieve can open the file and process some records but other times gets error. I suspect the errors occur when btrieve has to go to an area above 2gb in file. Had same problem with dos box, there couldn't even open the file, and was told problem was a signed integer was used hence then 2gb limit. That shelved the porting project till i discovered vdos. Better since i can at least opn the file but still a fatal problem to futher use. Other wise the old data base system runs good, prints searchs all fine except with the single 2gb file data base problem. Bob Swickle.
Btrieve will use DOS 21-42h to set the current file position for the next read or write operation. Registers CX:DX are documented to contain the signed (!) 32-bit offset, so that restricts it to -/+2 GB. Windows API allows for signed 64-bit values, but just interpreting CX:DX as an unsigned 32-bit is no solution: a negative offset can after all be used relative to the current offset or end of file.
It almost seems a bug or limitation of Btrieve. If it would have to position to an absolute position beyond 2GB, it needs to first do an absolute positioning below 2GB, followed by one or more relative positionings until the desired location is reached.
What version of Btrieve do you use? That 2.8GB file comes off a Netware server in combination with Brequest?
Jos
Btrieve is 5.10a network version loaded as a TSR. The 2.8GB file is on a network server, the error coming on a btrieve get record operation. No problem with the 2.8 GB file in pre Windows dos machines and 32 bit Windows XP, 7 & 8.1 systems running under standard cmd.exe dos window. Seems 32 bit Windows systems do something that makes Btrieve happy that vDos does differently.
Bob Swickle
The documentation of Btrieve 5.1 indeed states:
But the 32-bit combined CX:DX registers are documented as a signed offset (http://www.ctyme.com/intr/rb-2799.htm).
Probably there’s an exception for subfunction 0: Move to a position relative to the start of file.
I''l look into how NTVDM proceeds negative offsets with the 3 subfunctions and subsequent read/write operations. I'll report in a few days.
Jos
Hi Robert,
I have a question about Btrieve and the autoincrement key.
Are you using this option in your files ?
Many years ago I had to stop using this function because when the key value become 65535, the next value return by Btrieve is 0 instead of 65535.
Did you encounter the same problem ?
Thanks!
Sylvain
An unsigned 2-byte binary field can only store values from 0 to 65,535 (2^16-1). You need a 4-byte field accommodating 0 to 4,294,967,295 (2^32-1).
Jos
Hello Jos,
First, thanks for your answer even if it not the good discussion forum.
The probleme, is that my key is 4 bytes long as in this description :
File Stats for cpjidx.don
Variable Records = No
Number of Keys = 7
Page Size = 1024 Unused Pages = 0
Total Records = 2
Key Position Length Duplicates Modifiable Type Null Total
0 1 4 No No AutoInc -- 2
1 5 4 No No Integer -- 2
2 9 4 Yes Yes Integer -- 1
2 13 4 Yes Yes Integer -- 1
3 13 4 Yes Yes Integer -- 1
4 17 4 Yes Yes Integer -- 1
4 13 4 Yes Yes Integer -- 1
5 21 20 Yes Yes String -- 2
6 41 4 Yes Yes Integer -- 2
6 45 4 Yes Yes Integer -- 2
Is there a forum for Btrieve somewhere ?
Thanks again!
Sylvain
The first thing that comes to mind with Btrieve is: Rock-solid reliable database engine.
Essentially all my DOS programming was using Btrieve, though that was more than 15 years ago.
The file structure reported by Butil is correct (4 bytes, AutoInc), but does your programming language support 4 byte unsigned integers. Isn’t it just an interface problem, a 2 byte integer superimposed onto the Btrieve record buffer, misleading you? Can’t imagine a 4 byte auto increment key would wraparound at 65,536. The insert operation would also fail since the key is not unique.
Don’t think there’s a DOS Btrieve forum still around, if there ever was one, Btrieve was a mature specialized tool w/o issues (that I know of).
Jos
Bonjour Jos,
Thanks for your answer.
As you say, Btrieve is very reliable. I still use it today for my old DOS application in QB. Now with vDosPlus, I load it in the high memory.
May be I misunderstand the problem at the time I had it - duplicate key error. May be the problem was on the second key that is no duplicate too.
The tools that I had appreciated to used since I began in programming since 1985 is Btrieve and CA-Clipper.
Thank you very much for your contribution to the community of programmers!
You make DOS programs like QB still alive in 2017!
Sylvain
It turned out NTVDM treats CX:DX as an unsigned offset with DOS Int 21-4200h (start of file). While it’s considered signed with the other two starting positions.
I changed the vDos interpretation accordingly for the next version.
Jos