|
Post by jamesb52 on Mar 12, 2024 10:29:59 GMT 1
What about future use of your DOS program? Jos My family manufacturing business started with VisiCalc about 35 years ago, with floppy discs on Osborne computers. The floppies were painfully slow, but better than 12-column ledger books. Then discovered VP-Info, light-years ahead of dBase at the time, able to manage more and faster. Then upgraded to Sharkbase dbf-compiler on PC-MOS operating system for more users. Shark is compatible with all dBase, Clipper, and Fox dbf files, and can handle to 99 users & 4 billion records. This is an astonishing ability for a DOS database! Running on vDOS is even faster and less trouble-free. Shark on vDOS never crashes, which is a huge improvement. Everything works as it should, function keys, printing to files and to paper, bar-code scanners, even crunching those enormous PayPal reports! So we're delighted that vDOS keeps our old Sharkbase system running like it's state-of-the-art. Onlookers are astonished that they're seeing a DOS application on Windows.
|
|
|
Post by Jos on Mar 12, 2024 11:53:39 GMT 1
Glad you are pleased with vDos.
Support of up to 4B records however seems questionable. The LSEEK DOS API accepts an 32-bit offset. If the offset is absolute, it’s unsigned (max 4B). If relative to the current file pointer, it’s signed (max 2B).
With a record length of 100 bytes, record number 4B would be at offset 400B. Although not impossible, it would require a 200 (relative) LSEEK calls to get to that position.
So it will be support of database files up to 4B, not records?
Jos
|
|
|
Post by jamesb52 on Mar 13, 2024 9:10:21 GMT 1
Glad you are pleased with vDos. Support of up to 4B records however seems questionable. The LSEEK DOS API accepts an 32-bit offset. If the offset is absolute, it’s unsigned (max 4B). If relative to the current file pointer, it’s signed (max 2B). With a record length of 100 bytes, record number 4B would be at offset 400B. Although not impossible, it would require a 200 (relative) LSEEK calls to get to that position. So it will be support of database files up to 4B, not records? Jos The program-notes describe "records in a dbf file". The documentation says "unlimited records" (compared to dBase III which claims 65,535 records in a file). Other analysts have stated "4 billion". I've done a few test examples up to a million records which it writes out within a few minutes. I've never tested for 4 billion, but analysts have claimed "unlimited" or "4 billion" since it first appeared. Since it was created by mathematicians (e.g. George Gratzer of LaTex with others) for large statistical/geneology uses, I'm assuming they know how to explore limits. I haven't personally verified the speed and size limits except as noted here, but I can confirm it runs well on vDOS.
|
|
|
Post by Jos on Mar 13, 2024 11:00:49 GMT 1
A DBF file is basically an unordered sequential list of records. So its size would indeed only be limited to the available disk space.
But you want to access individual records in it based on some key, not read on average 50% of the file to find one. So a index file is created and maintained, that ultimately provides for the position of the record in the DBF file. If that position however is beyond 4B bytes, it can’t be reached/set by a single LSEEK call.
As said, for instance position 400B would require 200 LSEEK calls. That doesn’t seem feasible to handle such a large file.
Jos
|
|
|
Post by jamesb52 on Mar 15, 2024 9:32:40 GMT 1
Because tester feedback from long ago may be dated, it would indeed be interesting to know what the actual limits are today on bigger, faster systems. For my purposes, the limits are far greater than I would ever need. It may be that nobody knows! I'm mostly concerned that it manages 6 open indexed networked files at a time, and that it compiles everything quickly and reliably (compiling programs in DOSbox-x, for example, is like molasses compared to vDOS).
|
|