Announcement

**Jerry Mason** · 26 Aug 2003, 11:41 AM

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

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

**Kurt Schultz** · 26 Aug 2003, 11:49 AM

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.

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

**Herman Kieskamp** · 26 Aug 2003, 01:41 PM

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.

**Michael Mattias** · 26 Aug 2003, 03:37 PM

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

**Kev Peel** · 26 Aug 2003, 03:49 PM

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

**Kurt Schultz** · 26 Aug 2003, 07:57 PM

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

**Kurt Schultz** · 26 Aug 2003, 08:10 PM

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

**Kurt Schultz** · 26 Aug 2003, 08:17 PM

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

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

**Kurt Schultz** · 26 Aug 2003, 08:36 PM

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

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

**Michael Mattias** · 27 Aug 2003, 03:19 AM

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

**Tom Hanlin** · 27 Aug 2003, 02:44 PM

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

**Kurt Schultz** · 27 Aug 2003, 04:32 PM

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

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

Announcement

Sequential clobbers random

Sequential clobbers random

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment