Jon very kindly helped me sort out my logon issues and I tried to post an alert for tomorrow detailing my plan to activate Bardon Hill tomorrow at about 1300, but it doesn’t seem to be showing up in the Forthcoming Activations for tomorrow.
I think I filled the form in OK, I did get a couple of errors when I put a “=” instead of a “-” when entering the bands that I plan to take with me, but when I spotted my mistake it seemed to be accepted.
Anyone know how long alerts take to show up normally please?
It is quite surprising how often people try to post alerts with the wrong date often in January still using the previous year. The one that I cannot figure out is why we regularly see alerts posted for the year 2038. We have deleted several in the last 12 months and I see there is another one there now. I don’t know if the poster has a weather forecast for 2038 but his alert is conditional on the weather.
Jim
It’s when left-side-of-the-pond users put a left-side-of-the-pond format date into the system. I think one of Jon’s routines does some maths on the dates and the answer is 0x7fffffff which is when the Unix clock overflows. The Unix clock counts the number of seconds since Jan 1 00:00:00 1970 and overflows on 03:14:08 UTC on 19 January 2038.
I get bitten by such a convention at work ( I work for a left-side-of-the-pond company) and when I enter dates in right-side-of-the-pond format it all goes Pete Tong. I also have to reset my MS Office locale back to UK English once a month too.
See that’s the great thing about standards, there’s so many you just pick the bits you like and ignore the rest
Andy, a few days after the new year, my log suddenly stopped accepting new contacts. I manually upload s2s qso’s. They appear to be accepted, but my log is frozen at 1-1-15.
Is there a new procedure that I missed?
Yes US date format is quite amazing. Can you imagine your car odometer with the miles and tens of miles rotating as the 3rd and 4th digits from the right, then hundreds and thousands rotating as the 1st and 2nd digits from the right, and the rest rotating from the 5th digit from the right further left.
Completely logical,
Jim
Well it worked for me.
I could add chaser QSO manually and by importing a file.
I could add S2S QSOs manually and by importing a file.
I’ve found 2 issues. 1, you had a partially entered activation, I have deleted that as there was no data in it. 2. there’s now a S2S QSO for 8-jan-2015 in your log that won’t delete. I know why and will have a solution shortly I hope. It’s an index issue and the query is slow so it times out as it takes 6 secs longer than allowed. I’m just figuring out how to create the right index so that will be fixed soon, possibly tonight.
If you want “logical” the ANSI date format YYYYMMDD is the most logical. Sorts things in date order like a bought one. Format is obvious. No pond side issues.
Andrew
VK1DA
Agree 100% - All of my date/timed files are stored like that. What is irritating is the banks, utility suppliers and other vendors who continue to use file names with dates in the DDMMYYYY format that I have to change on every download.
Jim
Thanks Andy. Works nicely. I accidentally used 2014 after the turn and those contacts dutifully wedged themselves between my existing contacts from early January 2014. Not something that springs to mind while it’s happening.
For the uninitiated, the instructions say one should use a date of 08/01/2015, but the abbreviated 8/1/15 works as well.
It’s always nice to know things are sorted. What concerned me more was the fact that having had no problems adding records to your account was that I could not delete them. Ah, but MS-SQL Server Management Studio to the rescue… a quick “show execution plan” followed by “script missing index” and we were back in business.
When you delete an S2S contact, the database deletes the S2S part of the data (your summit) and the chaser part (their summit, date, band, mode). That’s easy but then it has to find out if there are any other S2S and or chases of the their summit for that day and if they score 0 should they now score something after this QSO is deleted. So it does a lot of scanning of files to find that. The index file speeds that up otherwise every chaser record in the database ends up possibly being scanned. That’s slow, in fact it takes 36secs to do it on average. Having created the index, the search takes 4 secs. It does it all as one transaction so the S2S delete, chaser delete, S2S score update and chaser score update all have to complete correctly or the deletes and updates are backed out and the original data restored.
