Announcement

Collapse
No announcement yet.

Sequential clobbers random

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

  • Sequential clobbers random

    Hi, folks -

    I've got a problem with a random-acess file that's been working successfully for years. I think what happened was someone tried to look at it with (MS-DOS 6.22) EDIT, and EDIT buggered the file when they closed it.

    It now gives a ORANGE screen of death.

    Any comments or suggestions?

    Kurt Schultz (Proud owner of PowerBASIC 2.2, et. seq.)

    ------------------
    Don't sweat it, it's only ones and zeros

  • #2
    Hi Kurt,

    EDIT has buggered many files for me over the years, usually by adding carriage returns (ASCII 13)
    at the end of the file. Check the file with a hex editor and look for "13"s at the end - by
    deleting them you hopefully will get your data back.

    Good luck,
    Jerry



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

    Comment


    • #3
      Thought it'd be something like that... I seem to remember sucking .BAT files into PB to strip them pesky CR/LFs that EDIT left behind (so that they wouldn't add extra prompts on the screen).

      .BAT files are sequential, though... this might be different.

      ------------------
      Don't sweat it, it's only ones and zeros

      Comment


      • #4
        Comment: Ever heard of backup ??

        Suggestion : Now serious, tough job, you have to be exactly sure as to what happened to the
        file, before you can operate, use only copies if you try something. The trickery part is
        if you use binary information in the udt or variables, they might contain decimal value 13 or hex &0D aswell.
        You have to analyze the file to see what really happened, try to find recursive things to get a picture if there
        is some kind of 'systematical' distortion in there. If so, it could be easy to write a file-fixer, if not,
        you have a big problem (manual binary editing) !

        Just to make you happy and give you some hope

        Herman.

        There is no such thing as a allround-random-access-file-fixer. (good word, many points for scrabble ).




        ------------------
        You gotta run, and don't loop back.
        You gotta run, and don't loop back.

        Comment


        • #5
          Something like this came up maybe a year ago.

          I suggested this..
          - Create the file as READ ONLY.
          - In your program, when you go to write it, change the attribute to read-write. (in PB/DOS, use ATTRIB statement).
          - Before you exit your program, change it back to read-only.

          Now the user will have to try much harder to hang himself.

          (For where you are now? Restore from backup).

          MCM

          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Just a tip for the future. Newer versions of EDIT allow binary editing with the /<nnn> switch...

            EDIT [/B] [/H] [/R] [/S] [/<nnn>] [/?] [file(s)]

            /B - Forces monochrome mode.
            /H - Displays the maximum number of lines possible for your hardware.
            /R - Load file(s) in read-only mode.
            /S - Forces the use of short filenames.
            /<nnn> - Load binary file(s), wrapping lines to <nnn> characters wide.
            /? - Displays this help screen.
            [file] - Specifies initial files(s) to load. Wildcards and multiple
            filespecs can be given.
            ------------------
            Kev Peel
            KGP Software
            http://www.kgpsoftware.com
            kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

            Comment


            • #7
              Hi, folks -

              At Jerry's suggestion, I went out on the 'net and bought a hex
              editor (well, it's that among other things; also claims that it
              translates EBCIDIC, which I'd forgotten existed, and it handles
              files up to 2Gig, and it can batch-edit multiple files, and a
              bunch of other sweet stuff).

              I got VEdit for DOS (US$29 at vedit.com). This was reccommended
              by a long-time friend that used to do code at SLAC.

              Looking at the ASCII/HEX dump of the random access data file
              convinces me that the file has been corrupted somehow (but
              probably not by loading into EDIT, as I'd thought earlier).

              To have something to compare against, I ran the utility I wrote
              ten years ago that builds the initial skeletal structure for the
              random-access file. It's 10,000 records by 64 bytes.

              It's nice of the editor to let me open both files at the same
              time, so that I can actually look at each of them in separate
              windows and glance back and forth to see differences.

              It's readily apparent that the second record is trash. The rest
              of the records look pretty good except for one thing that is
              troublesome: in the freshly-created file, all records end with
              "FFFF", but in the actually-used file, they end with a variety
              of 2-byte values. I'm inclined to think that a random number
              generator has been at work.

              I'd be interested in knowing if the two bytes at the end of a
              random-access file's record are significant (or if they are just
              "place-holders"). Anybody know? Tom, are you watching this?

              At least I can report some marginal progress to my client
              tomorrow (he's been snorting and pawing the dirt). I'll play
              around with it some and see if I can make magic. Hopefully,
              with this out of the way, I can move on to other problems that
              the code seems to be having.


              Kurt Schultz


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


              [This message has been edited by Kurt Schultz (edited August 26, 2003).]
              Don't sweat it, it's only ones and zeros

              Comment


              • #8
                Originally posted by Herman Kieskamp:
                Comment: Ever heard of backup ??

                Suggestion : Now serious, tough job, you have to be exactly sure as to what happened to the
                file, before you can operate, use only copies if you try something. The trickery part is
                if you use binary information in the udt or variables, they might contain decimal value 13 or hex &0D aswell.
                You have to analyze the file to see what really happened, try to find recursive things to get a picture if there
                is some kind of 'systematical' distortion in there. If so, it could be easy to write a file-fixer, if not,
                you have a big problem (manual binary editing) !

                Just to make you happy and give you some hope

                Herman.


                There is no such thing as a allround-random-access-file-fixer. (good word, many points for scrabble ).


                Hi, Herman -

                Yeah, not worrying about the back-up issue... the whole system
                got whacked in Jan. or Feb. and they've restored to the wrong
                revlev of the app. Oh well. I'm looking at the corrupted data
                file on my development machine (I had to make a DOS machine,
                and jeeze, I'd forgotten how to install MS-DOS), so the messes
                that I make aren't noticable to my customer.

                At least I can tell by reading the FIELD statements exactly how
                long each record is supposed to be. It was harder to figure out
                how to get the editor to display one record per line.

                The bigger problem was that an office manager threw away the
                customer's copies of the source codes for the project a couple
                of years ago. If it hadn't been for my archival copies, this
                whole thing would be hopeless. Make a note: if you write a
                programming contract, add a clause that allows you to keep a
                copy for your own archival needs!


                Kurt Schultz


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


                [This message has been edited by Kurt Schultz (edited August 26, 2003).]
                Don't sweat it, it's only ones and zeros

                Comment


                • #9
                  Originally posted by Michael Mattias:
                  Something like this came up maybe a year ago.

                  I suggested this..
                  - Create the file as READ ONLY.
                  - In your program, when you go to write it, change the attribute to read-write. (in PB/DOS, use ATTRIB statement).
                  - Before you exit your program, change it back to read-only.

                  Now the user will have to try much harder to hang himself.

                  (For where you are now? Restore from backup).

                  MCM


                  Hello, Michael -

                  I wrote file locking into the app years ago. The
                  unlock-modify-relock process is all automatic and not supposed
                  to be apparent to the User. While I mentioned it to the
                  customer (way back when), my guess is that he's forgotten it's
                  there.

                  Unfortunately, the system was "restored" by the Dr.'s "network
                  guy", who knew enough to use ATTRIB at the command line.

                  Can't make this stuff fool-proof (even though I've tried).

                  It's a good tip, though - the rest of you, pay attention!


                  Kurt Schultz


                  ------------------
                  Don't sweat it, it's only ones and zeros

                  Comment


                  • #10
                    Originally posted by Kev Peel:
                    Just a tip for the future. Newer versions of EDIT allow binary editing with the /<nnn> switch...

                    Hey, Kev -

                    Thanks for considering this, but I want to make a blanket
                    prediction here:

                    <EMPHASIS> There is absolutely NO WAY that I will ever
                    knowingly put this file inside of a Microsoft editor! </EMPHASIS>

                    For this project, I'd go back and re-install WordStar before I'd
                    use EDIT to look at this file. WS' Non-Document mode leaves a
                    file untouched if you abandon your edit session.

                    Also, I've got a couple of other old DOS editors around that I
                    might be able to use for this, like TED and Bingo, and maybe
                    some others.

                    I tried to use PB to look at the file, but the record/line
                    skewing skewed with my head and I couldn't see what I was
                    supposed to be looking at.

                    Anyway, thanks, but no.


                    Kurt Schultz


                    ------------------
                    Don't sweat it, it's only ones and zeros

                    Comment


                    • #11
                      Unfortunately, the system was "restored" by the Dr.'s "network guy", who knew enough to use ATTRIB at the command line
                      You gotta love those users who know just enough to be dangerous.

                      Right now I'm putting together an application going out to about 5000 users (in a curious coincindence, these will be mostly doctor's offices!).

                      I am currently seriously considering putting the "INI" file settings into a separate DLL and using UpdateResource to store the settings as user-defined resources or string table entries just to remove the temptation for some of these users to set parameters using "Notepad" instead of the "System Setup" screen.


                      MCM




                      [This message has been edited by Michael Mattias (edited August 27, 2003).]
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        I'd be interested in knowing if the two bytes at the end of a
                        random-access file's record are significant
                        The contents of files opened for BINARY or RANDOM access have no
                        significance to PB/DOS. As far as the compiler is concerned, the
                        contents are simply raw data.

                        ------------------
                        Tom Hanlin
                        PowerBASIC Staff

                        Comment


                        • #13
                          Originally posted by Tom Hanlin:
                          The contents of files opened for BINARY or RANDOM access have no
                          significance to PB/DOS. As far as the compiler is concerned, the
                          contents are simply raw data.

                          Hi, Tom -

                          The mystery of the two 'extra' bytes at the end of the random
                          access record was solved when I went back and looked at the
                          source code again. They are there to store the Dr.'s "chart
                          number" for each patient. They aren't "random", they are
                          sequentially generated (but because the records are sorted
                          alphabetically by last name, that field appears to be random).

                          A phone call to Florida helped straighten out my
                          misunderstanding, so I looked further into the source and there
                          it was, practically jumping up and down.

                          I'll take an order of humble pie now... with coffee...

                          At least the ASCII/HEX editor let me strip out the record that
                          was trashed, and insert another 'fresh' record (to keep it in
                          balance). I'll probably get to find out tomorrow if it works
                          as it should.


                          Kurt Schultz


                          ------------------
                          Don't sweat it, it's only ones and zeros

                          Comment

                          Working...
                          X