It is true that the mentioned use of an external database adds some complexity and problems. These data bases are well equipment for handling LARGE number of data elements (e.g. your whole qso history as in case of CQRLog).
What we discussed for TLF was mostly the use of an sqlite database which would be an integral part of TLF. That makes maintenance much easier. Additionally a contest log has much less number of database elements - as long as you do store only a single contest in each of it. As an interesting sidenote you will also find a database at the heart of the widely used N1MM logger. Here it seems not a problem for anyone. Anyway I agree with Alans remark about using a separate tool for doing statistics on your contest data. 73, de Tom Am Thu, 28 Dec 2023 09:56:44 -0500 schrieb Alan Dove <a...@alandove.com>: > Hey, folks: > > I'm opposed to having TLF rely on a database. It adds complexity and > failure points, and shouldn't be necessary for any forseeable contest > log. > > Users who want a tool to collect QSOs from multiple contests for > analysis, DXCC tracking, and so forth should use a separate > application. CQRLog does all that and more, and also exemplifies the > kinds of support problems a database can add - just browse through the > CQRLog forums for tales of woe from users who can't get the database > connection working properly. > > Networking should definitely be a higher priority. > -- "Do what is needful!" Ursula LeGuin: Earthsea --
