I'm interested in a linked list tool set in source that can be used
with PB 3.5 ...
I can forecast an easy more than 125,000 parent listings. They each
could have a maximum of about 2048 bytes of a specific common organized
struct, UDT, Union for up to a maximum of about 24 such pointers
needed per parent listing. Since structure of the common organized
blocks of data is fixed in size and fixed in orientation and purpose for
every member in the defined block of data, I can contemplate even
rebuilding the parent list by back pointering to it even if things
blew up, but I was still left by the linked list.
Obviously, the someodd 6,000,000,000 bytes of possible data that would
be involved here are beyond the size limitation of DOS partitions.
But as luck would have it, the average parent would be expected to
have not more than four child relationships to the data. Thus in
theory, one could postulate no more than a 1,500,000,000 byte file
for the data file. That's still within the realm of DOS operations.
A side pig trail here! Yes, DOS files can't be bigger than 2GB in
theory .. or can they? What about a BINARY file on a larger than
2GB partition which is simply told to offset and go get 'em tiger?
Say you go to put a binary file beyond the limit! Will 'e not go
there and put 'im because a tiger won't eat what a tiger can't smell,
or something like that?
I did a list search in the SOURCE code part of the forum for the
phrase "Linked List" and came up with only one hit. It was a WIN
contribution.
Since I'm already working with BTRIEVE successfully, would it be the
thought here that the fastest, safest, critical data manipulation
deal would be to create this with driver code to do this in BTRIEVE?
Or, since the data is ALWAYS going to be field stable as to size,
form, and purposes in the big data file, would I be safe to try this
creature in just a BINARY mode file which could have, a maximum of
maybe 600,000 blocks in such a file?
Hopefully, this will never have to leave the PowerBASIC camp as it
moves forward to LINUX and fields unknown. But if it does, the less
proprietary stuff I have to deal with, the better off things will be!
Advice?
------------------
Mike Luther
[email protected]
[This message has been edited by Mike Luther (edited July 22, 2002).]
with PB 3.5 ...
I can forecast an easy more than 125,000 parent listings. They each
could have a maximum of about 2048 bytes of a specific common organized
struct, UDT, Union for up to a maximum of about 24 such pointers
needed per parent listing. Since structure of the common organized
blocks of data is fixed in size and fixed in orientation and purpose for
every member in the defined block of data, I can contemplate even
rebuilding the parent list by back pointering to it even if things
blew up, but I was still left by the linked list.
Obviously, the someodd 6,000,000,000 bytes of possible data that would
be involved here are beyond the size limitation of DOS partitions.
But as luck would have it, the average parent would be expected to
have not more than four child relationships to the data. Thus in
theory, one could postulate no more than a 1,500,000,000 byte file
for the data file. That's still within the realm of DOS operations.
A side pig trail here! Yes, DOS files can't be bigger than 2GB in
theory .. or can they? What about a BINARY file on a larger than
2GB partition which is simply told to offset and go get 'em tiger?
Say you go to put a binary file beyond the limit! Will 'e not go
there and put 'im because a tiger won't eat what a tiger can't smell,
or something like that?

I did a list search in the SOURCE code part of the forum for the
phrase "Linked List" and came up with only one hit. It was a WIN
contribution.
Since I'm already working with BTRIEVE successfully, would it be the
thought here that the fastest, safest, critical data manipulation
deal would be to create this with driver code to do this in BTRIEVE?
Or, since the data is ALWAYS going to be field stable as to size,
form, and purposes in the big data file, would I be safe to try this
creature in just a BINARY mode file which could have, a maximum of
maybe 600,000 blocks in such a file?
Hopefully, this will never have to leave the PowerBASIC camp as it
moves forward to LINUX and fields unknown. But if it does, the less
proprietary stuff I have to deal with, the better off things will be!
Advice?
------------------
Mike Luther
[email protected]
[This message has been edited by Mike Luther (edited July 22, 2002).]
Comment