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:[EMAIL PROTECTED] 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#$^&@[EMAIL PROTECTED]&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
