G'Day Mauro,
I run a SO2R SSB/CW/RTTY contest station using Elecraft K3s and MicroHam equipment. I run Logic under Win 7 using triple 19" 1280x1024 monitors configured as ONE wide screen. The contest logging is done using N1MM from which the ADIF log is imported into Logic 8. I am moving to Logic 9. I do all my contest analysis and reporting in Logic. My Logic database QSO count is approaching 20,000.
The maximum number of user fields has been an issue for years. The maximum used to be 10 and is now 20. The limit of 254 characters for all the user data for a QSO will probably never change. The number of defined user fields has always been unlimited, as has the number of log forms.
From what you write and the images, you are doing exactly what I used to do. Recording what radio was used etc. You record how you made the QSOs, recording the data in user fields you define. You record not only that you made a QSO, but how you made the QSO. I also recorded under what conditions - sunspots, Kp, Ap etc, and much data related to QSL - county, shire, parish, lighthouse, provence, JCC, Guns, Prefecture etc etc.
You may already understand some of the things I will list. I do so to make sure we each understand the same things.
I no longer do as much as what I describe below. I still record a lot of user fields for contesting, but I abandoned much of the work several years ago as I simply did not have the time to keep all the data up to date for DXing. Family commitments have often limited the time I can spend on amateur radio. Hopefully those times have passed now I am retired.
One can have a lot of user fields defined - as many as one wants. (Tools, Setup, Log Fields)
There is a limit on the total "text length" of all the user fields used for any ONE QSO - 254 characters. This is the Logic database field called "USERFIELDS" - where the data for the user field is stored. You can display this field with the Log form called USERFIELDS - as your screen shot shows.
All of that has nothing to do with the 20 user fields one can have on a Log form. Each and every log form is LIMITED to the display of 20 user fields. But each Log form can display 20 different user defined fields.
So, if one wants more than 20 fields for a QSO on the screen at any one time, one must use two (or more) Log forms.
But, as you have discovered, there are problems to synchronise the two (or more) forms - keep all the data visible on the screen at the same time. One has to move the form to a new record, click with the mouse. The "browse window" will update, but only if one clicks on the window. Synchronisation of the forms to a databse record, a QSO, does not happen automatically.
This limitation cannot be overcome easily, because of the way the Visual Foxpro database software works, and the way it has all been assembled together by Dennis to form the Logic program. It is a limitation we just have to live with.
So the reality is that, if there are more than 20 items of user data that you want to display at the same time, you have to use separate Log forms.
How can we over come the problems of form synchronisation?
I over came the limitations by realising that my user data was of several distinct types …
- QSO data: mode, DXCC, time, country, IOTA, zone etc etc.
- QSL data: county, state, provence, lighthouse, etc
- Station data: radio, antenna, amplifier etc
- Conditions data: 10cm flux, sunspots, weather etc etc
You may be able to divide up your user data differently.
Also, I realised that one can print an unlimited number of user defined fields in a printed report. In reports there are no limitations.
So we are left with two problems: the limit of 254 characters total, and the fact we cannot display more than 20 user fields on a single form.
The total number of characters for user data for a QSO is 254 - this includes the name of the field and the actual data. For example, for CQZ, that means "| CQZ:25" the separators, the name of the field, and the actual zone - 8 characters. So for any QSO the absolute maximum number of data items (different user fields) one can record for a QSO is 254/5 - that is 50. This assumes ONE character for the name, ONE character for the data, and three characters for the "separators" to manage the data.
This is impossible - few fields would be only ONE character. A more realistic user field length would be 10 to 15 characters. A US County is something like CNTY:MN,OLMSTED - 17 characters!
So we can define 50 or more, but only store 30 or so in the database record, and only display 20 of them on any one Log form. And that assumes the charatcer limits I selected.
My solution …
Each Log form is a separate "window" onto the database. Each moves through the data (the data base records of QSOs) independently. So using lots of forms to scan through the database is easy - one form for the QSOs, one form for a QO and my equipment, another form for the QSO and radio conditions. I rarely needed to look at all the data at one time.
One can use any log form to record a QSO. But, while the update is occurring on one form, the database record is "locked" and cannot be updated in any of the other forms. Any new record will not be seen by the other forms util written to the database. This is normal database behaviour and happens in any database program, not just Logic.
I found big single log forms were a bad idea - too many limitations.
I created smaller, different, Log forms for the different data types, and created many different reports to print the information for QSOs.
For actual on air logging, I created Log forms for different directions. A Log form for JA QSOs (JCC, Prefecture, Guns), another for K QSOs (Country, US State), many to record QSLs for each DXCC, and others for looking at what equipment I used, and radio conditions in what QSOs.
When working DX, or rag chewing, I created several Log forms and carefully chose which 20 (of the 50 or so) user fields I would have on the form. I would use a different form for working DX in different directions. I clearly did not need "US Country" while working EU late at night. Each form had common user-fields for a QSO - IOTA, 1010#, etc and different forms had different unique fields for the specific DX I was working. The log forms included nothing on the form for user fields that I could populate later using the Tools, Advanced, Database Commands tools that Dennis provides.
Using the space created by the multiple display screens, I often had 10 Log forms open at the same time. A form of each type was in view at any one time, with forms of a similar type behind forms of the same type. I use the Window menu to find them. I would often work one station with one form, move the VFO, find different DX, and once I had the call sign, switch to the correct form to log the QSO. After the DX session was over I used other forms to enter data or mass update all the QSOs.
For some fields I only entered data after I got a QSL card. I have different forms for QSLing for different DXCC. And, after QSOs were made, I used Tools, Advanced, Database Commands, Mass Change, Replace User-Defined fields contents to enter data for many QSOs. I used "Change User defined field contents" for things like Radio, 10cmflux, antenna, weather - things that do not change from QSO to QSO over a few hours while working DX or a contest. These fields never appeared on the Dxing forms, only on my "analysis" forms.
Because of limitations on my time, my main activity has been contesting. I use N1MM and import my logs to Logic.
Using Logic, one can import different ADIF named fields moving the data into the Logic fields and user defined fields. One can translate from a external ADIF field name to a different Logic defined name. But, there are limits.
One can have a user field say RX, and import from a field in N1MM called APP_N1MM_RADIO_NR. In Logic8 the external field was limited in length, but I see in Logic9 it is now quite long.
The ADIF import/export limitations can be annoying. I agree, it would be great if we had a "table of relationships" for each field for each program. It would be great if all the logging programs used the same names, but I don't think that will ever happen. We should rejoice that Dennis (with a few others) was the initial creator of ADIF and attempted to address these problems.
If one wants to import ADIF data from several different logging programs - in may case HRD, N1MM, WINTEST, WRITELOG - one needs to carefully edit the ADIF definition in Logic for each import/export. Logic8 was limited in the external name length so I changed to using SED, AWK, PERL to edit the ADIF logs before/after import/export creating a common name which was translated by Logic into the Logic user fields. Much easier, and I have now automated the process and it takes only seconds after every contest for thousands of contest QSOs. This external editing is what you seem to do.
I think the intention was that in each Logging program there was a "translation" table so moving data would be simple. But many programs simply import/export their own name with no translation possible. Logic provides "translation" from one name to another. The limitations you are seeing are actually in the other programs - not Logic.
Logic9 has a much longer field for the external name so, given I mainly use N1MM for contesting, I will be moving to a direct import into Logic9 without the prior editing of the ADIF file. See attached image. But that will mean for an import from WinTest, I need to edit the name relationship in Logic - WinTest has no such "translation" like Logic. The same implies if I need to export ADIF data to other programs. The limitation is in the import of the other program.
Peter VK4IU
Peter VK4IU
You can help by posting images of
any errors and including your
Logic version.