This announcement is to let database users know of a proposed update to the database. With advanced warning nobody will get caught out by the changes!
The change will only affect people who upload logs using the CSV upload facility. If you enter your logs through the webpage then you will not see any changes.
I intend to tighten the requirements for CSV files being uploaded as a number of users are uploading malformed data. The effect is that the filters on the log viewing pages are unable to work correctly. Over the past months I have run a number of cleanup scripts on the database to fix common errors but I’m getting fed up fixing the same problems again and again. It’s not really a user problem per se, it can’t really be a user error if the database accepts the submission. It’s more a design decision that now needs reviewing in the light of accumulated observations.
The biggest source of malformed data is the Band field. The webpage entry forces the user to pick from a list of descriptors such as 7MHz, 144MHz, 21MHz etc. I do see users entering 20m, 40m or 10m etc. The problem is that that trying to view all contacts on 14MHz will not include contacts logged as 20m etc. as the software looks for “14MHz” in the data. Worse is when 40m is entered as 40MHz, or 15m as 15MHz.
The new parser will reject obvious errors like 40MHz etc. but I haven’t decided whether it will allow, for example, 40m in the input and convert it to 7MHz or if it will only allow the same fields as the webpage entry. I feel that the software should not try to second guess what the user really means and should only allow valid data and should reject anything else. But I’m happy to listen to other user’s views before I change anything especially as I have yet to write any parser updates.
Yes, there are other updates/bug fixes/features the database needs, some of which may also roll out with this update so you don’t need to ask for the confirmation * to be turned on again!