No announcement yet.

Linked Lists in PB 3.5

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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

    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!


    Mike Luther
    [email protected]

    [This message has been edited by Mike Luther (edited July 22, 2002).]
    Mike Luther
    [email protected]

  • #2
    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.


    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3

      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 hard
      error. As noted in my last post.

      Jim Gillem -