Linked Lists in PB 3.5

Could be too simple but..

In one of my apps I simply stuff the parent record (pr) in each
sub record (file) so that when a user enters a unique transaction
code/MR# medical record ,invoice or any other ID number it goes
direct to the sub item via that number/string finds the parent
pr#, then jumps to the "parent" rnd file record that then links
back to any related sub records AND no sorts are needed...
used this on a Univac 1108 drum in the 70's

This lets the sub records have expansion room. (no real limits
except disk size..) Of course the "parent file can be sorted or
Btree'd or whatever.

Works for me.....

I do hope the LINUX (pd-lnx?) vsn removes then 640k barrier and
will give us all hi mem without any "mumbo jumbo".
We all need it.

By the way - re: DOS PRINT: I have found that a DELAY OF .9
PRIOR to shell (ultra) seems to help defeat the command.com hard
error. As noted in my last post.

Jim Gillem - magnumsoft.com





------------------

[Michael Mattias]

I Like the btrieve idea, but...

Why not store the parents in one file (about 500 Mb, if my artithmetic is right: 2K bytes/parent * 125K parents = about 500Mb) and the children in a second file of about 1Mb? (1.5Mb total less 500K in parents).

Maybe it won't be a "linked list" anymore, but once you find a parent, you can sure find the children.

MCM

[Mike Luther]

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).]