HI,
I don't think that database issues are among important ones, and we already
discussed the matter several months ago, so I'd just like to add some new
observations.
One of local TR users noticed me next: when he added manually (with text
editor) some calls w. additional datas to the end of TRMASTER.ASC file and
converted it into .DTA file, everything was OK - calls, names and other
datas appeared correctly in the window, when he typed in those calls. But,
when he converted .DTA file back into .ASC one, all those calls dissapeared
from the file, (and he couldn't find them with Search function of the editor
he is using).
I tried the same with my database and found the same. No matter which way I
enter new data (be it within POST U E E, or adding them manually at the end
of .ASC file, either creating new, short .DTA file with just new calls in it
and merging new .DTA with existing one with POST U E F D), always happens
the same. The calls does exist in .DTA file and dissapear when you turn the
file into .ASC format. Maybe my own database file is too large (nearly
120.000 calls in it), but friend's one is not as large as mine... Maybe the
answer for dissapearing calls, mentioned by VR2BG several months ago doesn't
lie in how large particular cells are (S5 cell in my database is now as
large as 77800 bytes) but in reading binary (.DTA) file and converting it
into ASCII one? In the ASCII file I saw some busted "calls", say Z32 =H1,
ZW5, YU1, etc. After erasing them, converting the database into .DTA and
reconverting back into .ASC format, those "calls" #reappear#!
For usage in particular contests, I created some smaller databases,
containing just S5 calls, or only EU or NA calls, etc. Instead of having
them in particular directories, it would be nice to have them all in TRLog
root directory, with possibility to choose desired database either from
startup menu (same as you choose .CFG files), either adding trmaster file
name into .CFG file, without need to rename them first. However, as I said
at the beginning, database issues are of low priority. :-)
Thanks for an excellent piece of software, I'd never change for any other!
73!
Mirko, S57AD
|