I completed an activation but saw that I left one out and another the operator gave me the wring call sign ( I know this guy he is a mentally challenged young man and gave me the wrong call by mistake. A few of us are helping him)
Anyway without completely deleting the activation and starting over how do you add a qso and edit a qso.
Ken’KN6CCW
In reply to KN6CCW:
At this point there is no direct way to edit an activation log, to my knowledge. That would be a great feature!
You can download the contacts as a CSV file, I believe. Then add and/or correct the log as necessary, then upload the entire file.
73,
Linda
AB7YL
In reply to KN6CCW:
.
It’s supposed to be listed first in the FAQ’s, Ken, but that will be next year…maybe. In the mean time, try this:
On the database page, select View Results, then My Results, then My Activator Log, then go to the line with your activation in question. In the right-hand column, select Download. If that column isn’t visible, then log in and return to that line in question to select download. The download will go to a location you select in your computer, such as Paint or Note Pad or Excel. Mine goes to Open Office. Save it. Open the file and make corrections or add/subtract lines. Re-save the file with EXACTLY the same name and file type used at the start of the download. Once you have confirmed that it is saved, then…and only then…do you go back to your activator log and delete that entry in question. You have to do the deletion at this point because the database won’t let you upload your new file otherwise.
Now, go to Submit Log, then to Submit Activator TSV/CSV, then click Choose File. A window will come up with your computer’s saved documents, including the corrected entry, which looks like: K6EL_activationID_112496 (with no spaces) and has the current date. Click and open that file. Back on the database page, click Upload File. Done. Optionally, you can then wait a minute for the server to finish digesting your handiwork, then look at your activator log to see the changed entries.
.
Elliott, K6EL
In reply to K6ILM:
Thank you. That worked very easily.
Ken
Hi
To edit an activation or chaser log, would be a great feature!
tks in advance es 73 de HB9BIN, Juerg
In reply to HB9BIN_3:
To edit an activation or chaser log, would be a great feature!
Or maybe a simple web api, that allows someone to download, upload and delete ones log-entries program-controlled, without the need to use the web interface manually.
I guess this would be less time-consuming to implement and I assume sooner or later an ingenious SOTA-enthusiastic SW developer will provide some comfortable logging application, that makes use of such an interface.
73 Stephan, DM1LE
In reply to DM1LE:
One the reasons online editing is pushed way down the jobs list is because you can do this with several programs available already.
Andy
MM0FMF
In reply to MM0FMF:
Andy, I fully agree with you, logging applications or even spreadsheet applications make it very easy to enter someones logs and export it to the SOTA V2 format.
Things only get very tedious if you find some errors after uploading the log to the SOTA-database. Then all (or most) of the steps, that were described above by Elliott, must be executed manually, i.e. find your activation in the web interface, (optionally: download to csv-file,) delete the activation, edit with an external editor and re-upload the file again.
My idea was, that exactly this tedious steps might be executed automatically by an external logging application, if the user presses the “Update” button in the applications GUI. But this requires IMHO some simple access to ones logging entries in the SOTA-DB. But I must admit, I didn’t ponder on security or safety issues.
Nevertheless, it was just an idea and I don’t mind if it has a low priority.
73 Stephan, DM1LE
In reply to DM1LE:
“…sooner or later an ingenious SOTA-enthusiastic SW developer will provide some comfortable logging application, that makes use of such an interface.”
Maybe, and I’m sure there are enough such developers around - but none of them have access to the SOTA db. Therefore, since it’s low priority, users in 2014 will just have to continue wrestling, for the foreseeable future, with a web interface featuring all the user-friendliness and flexibility of something built in 1994. But the saying “If it ain’t broke, don’t fix it…” comes to mind.
Rob
I just don’t see why there can’t be an “edit” button on the activation and the same for a log on that activation.
Mistakes happen. I mean I were perfect I could walk to heaven. It would be nice to be able to fix issues.
In reply to DM1CM:
But the saying “If it ain’t broke, don’t fix it…” comes to mind.
True words, Rob. After all the mails I’ve sent to you concerning the SOTAmapping project, you know me well enough, that the intention of my suggestion above is not to complain about the web interface of the SOTA database, but instead to provide some ideas for further improvement or extension.
In my opinion, your SOTAmapping project is a very good example how SOTA benefits from “third-party” applications, i.e. applications that make use of the information available in the SOTA database but which were developed by non-SOTA-MT members. In a similar way “third-party” logging applications could provide comfortable editing features and thus would supersede any improvements in the web interface of the SOTA database. The only requirement would be a “tighter” integration interface between the logging application and the SOTA database, that is to say more openness of the SOTA database. But that’s only my humble opinion.
73 Stephan, DM1LE
In reply to DM1CM:
Would probably need something similar to this for the web database user interface developers
73, Jaakko OH7BF/F5VGL
In reply to DM1LE:
Stephan, yes, I’m well aware of your openness in these matters, and I have cause to be grateful for that. However, I’m not so sure that opening up the SOTA database is the issue - I think the MT should be more prepared either 1) to learn new web technologies and become familiar with accepted GUI (graphical user interface) design standards; or 2) to open up their core team to allow in people with those skills. But this is only my personal opinion, and YMMV…
Databases SHOULD have a very restricted number of users (I speak as a seasoned database administrator) and, in the case of web-based applications such as SOTA or the SMP, ideally two users only: one as admin with full rights to everything in the db and the other as “application user” with tightly-restricted rights to allow access only to what the application needs. So, I’m prepared to say that I’m definitely not for opening up the database to all-comers - that direction leads most often, eventually, to chaos.
There is another problem, of which I’m aware, with regard to the suite of SOTA/SOTAWatch software, and that is the fact that at least two different combinations of [database + server-side language] are used. On the one hand they have [MySQL + PHP], and on the other, [MS SQL Server + MS .Net C#]. I’m familiar with both combinations (they’re very different!) and I must say I admire the tenacity with which the MT hold on to both systems - it can’t be easy to maintain. And I feel fairly confident in saying that, if the MT had to start over again from scratch today, they would choose only one of those combinations. I hasten to add that I think their system is, well, not bad at all ;-). But again, YMMV…
However, as somebody pointed out to me a long time ago on this forum, SOTA is not a club where the members have a vote to say what goes - and that’s fine by me. SOTA and the MT open their doors to us much in the manner of somebody giving a party - if you like the music, OK. But if you don’t like the music, you could ask them to change the music - but it’s their party, and they can play whatever music they want. And if you don’t like it: find another party… Which, again, is perfectly acceptable to me.
Rob
In reply to F5VGL:
Jaako, I think what Dan OK1HRA and Martin OK1RR have done there at HamQTH is admirable - as far as it goes. But most of the database access tools they describe are for searching data, and (not by coincidence!) very similar to the QRZ.com developer’s API. Admittedly, they do have some means by which users may upload their logs, but these are just as clunky (“blind” uploads) as those offered by the SOTA website. So, with respect, I would say no: I don’t think that’s the way to go.
The way to alter the data in one, or a few, QSOs is this in a nutshell:
The user has all his data at his disposal, can see it on the screen, can change it line-by-line or in complete blocks, and see the changes straight away. This is not rocket science, folks.
Rob
In reply to DM1CM:
coincidence!) very similar to the QRZ.com developer’s API. Admittedly,
they do have some means by which users may upload their logs, but
these are just as clunky (“blind” uploads) as those offered by the
SOTA website. So, with respect, I would say no: I don’t think that’s
the way to go.
Database maintainers are not always the best experts in making user friendly interface. I do not know if this kind of online log editing has been done already somewhere. It is not supported by LoTW nor by HamQTH nor by the present SOTA database. For eQSL or QRZ I am not sure. If this online editing is done at the central server it is of course easiest for the end user. The other possibility that I was proposing is to make it possible with POST and GET methods and leave it to the user community to do it correctly. You might loose some valid data from the database if there are any bugs in the end user scripts and programmes.
73, Jaakko OH7BF/F5VGL
In reply to F5VGL:
“Database maintainers are not always the best experts in making user friendly interface”
Jaakko, correct! - most of the time. In my own defence, I would add to my above statement re my db admin experience some 10 years of DOS database application programming, twenty years of Windows database front-end applications using OO programming languages (plus using the Windows API), twenty five years of website design, construction and administration; seventeen of those years building web-based database front-ends. So I think my comments may be seen to bear some weight. As always, YMMV…
Rob
In reply to F5VGL:
“The other possibility that I was proposing is to make it possible with POST and GET methods and leave it to the user community to do it correctly.”
Jaakko, in principle, this is a fine idea, and there are any number of web authors who could create the front end. But it relies on the SOTA programmers creating the back end on the server: a script which accepts those POST/GET parameters, checks them for errors and inconsistencies, also checks them for possible intrusive code, etc. They might just as well create the whole package: input page for alterations, etc.
This was the point behind what I was suggesting: that the whole thing stay behind the SOTA “wall”, where everything can much more easily be controlled. But this means that the SOTA programmers have to create the package - and I know for a fact that they’re worked off their feet right now. So the whole thing stays where it is: far down in the list of priorities.
Rob