Announcement

Collapse
No announcement yet.

Linked Lists in PB 3.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jim Gillem
    Guest replied

    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





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

    Leave a comment:


  • Michael Mattias
    replied
    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


    Leave a comment:


  • Mike Luther
    started a topic Linked Lists in PB 3.5

    Linked Lists in PB 3.5

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