[Dx4win] Unhappy with DX4WIN

[Robert Naumann]

Why are you posting a message sent only to you to the reflector?

You obviously don't need my help.

73,

Bob W5OV

-----Original Message-----
From: Mike Mellinger WA0SXV [mailto:wa0sxv at mellinger.com] 
Sent: Monday, January 07, 2008 9:08 AM
To: 'Robert Naumann'; dx4win at mailman.qth.net
Subject: RE: [Dx4win] Unhappy with DX4WIN

Hard to believe that you are me lecturing on software design and operation.
Let's just say I have a bit of experience -- about 4 decades in software
design, implementation and support including primary design responsibility
for online library systems indexing and storing millions of records and
handling 10 or 20 million transactions a year.

But you wouldn't know that.

You merely verify what I've been saying.  The log file is not monolithic nor
is it sacred.  The information is scattered among multiple files -- at least
two that I know of.

The index out of range error is reporting on the country file, not the log
file.  The message only occurs when adding new mappings.  It can obviously
be fixed by going back to the old country file before the error.  The log
file is not structurally corrupt.  It works fine and can output the complete
log without error.  In fact that was how I verified the damage -- I output
everything to a .CSV file and did the same with an old log.  I then compare
them using an ASCII compare.  Same thing that I have to do every time I get
a new country file.  Something like 20,000 entries changed.  That was when I
knew that there was a serious problem.  I wouldn't have even been checking
this except for a note on this circuit about losing the information due to a
bug in the country file update.

There are lots of excuses possible for the defective design of these file
structures.  I suspect most trace to trying to minimize log size by avoiding
any possible replication of data.  Disk and memory used to be expensive.
But by doing so your log is subject to any of two or more files going bad
instead of one.  This doubles the possibility of damage due to hardware.
And it increases the possibility that the damage will be very hard to
recover.

After sifting through a couple of dozen backups I have found a copy of the
country file and log file dated immediately before the problem.  I only had
about a dozen Q's since then and two contest logs imported.  Since my
contest logging is done with another program I have ADIF copies of those
logs and can easily reimport.

So now I get to go back to the old files, find the "approved" procedure for
adding the new countries, add them, test the results.  If successful I can
enter the Q's necessary by hand and reimport the logs.

Could have been worse.  But shouldn't have happened at all.

As for all of you saying how happy you are: that doesn't change the facts. I
was happy too until I got bagged by the defects.

73,
Mike WA0SXV



-----Original Message-----
From: Robert Naumann [mailto:w5ov at w5ov.com] 
Sent: Sunday, January 06, 2008 20:41
To: 'Mike Mellinger WA0SXV'
Subject: RE: [Dx4win] Unhappy with DX4WIN

All country mappings are maintained in the country file. 

If you over-write them, *you* over-write them. If you replace your correct
country file with a new one from AD1C that does not contain all the
corrections you may have added, those changes you added to your old file
will not magically be added to the new file.

The changes you made do not get screwed up. You threw them out by replacing
your original file.

Big difference.

If you are getting error messages like you claim, "index out of range
error", the integrity of the actual data inside the file may itself be
corrupt. This has nothing to do with file system integrity.

For example:

A valid record could be something like:

20080106 2359 9Q5DX 14.243 Joe etc. etc.

Instead, something like this could be in there:

2008#$^&@%^!2359$^%!@$#&E$$%^#$%^#$%$^%$^5DX$^*#$^*$%*$^&*!#$^$!#%$&^$%Joe

A "shadowed" drive provides no protection from data corruption, and will
keep two copies of a file containing corrupted data. It does nothing to
assure that your file's data is not corrupted. File corruption is caused by
many reasons such as power turning off during a write process, not shutting
down your computer properly (pulling the plug, power failure) or other
similar actions.

Scanning will not detect such a problem, and backing up a corrupted file
simply makes a backup of a corrupted file.

73,

Bob W5OV