OK/MO-016 and EA4/CC-020 are both simple border duplicate summits. The alternative references, SP/BZ-036 and CT/AA-004, will remain. So there is no hurry!
DM/RP-444 was a slightly odd case. Michael tells me it was meant to be the Kuhnenkopf summit, which has low P, but I suppose it may have been open to misinterpretation as a dupe of DM/RP-494 for the reasons outlined above by John.
Any chance your updates to W4C will happen soon? The errors are causing issues with activators attempting to visit mis-identified summits.
TIA,
Dean ~ K2JB
Iāve got a script that fixes the name/summitref confusion that happened recently. I have not applied it yet, Iām considering what the implications are for people who have chased or activated the affected summits. But it will be applied sometime this week.
Some have made their corrections and notified their chasers, while others have been waiting for the database to be corrected before making revisions/notifications. I will notify all of the affected activators once the corrections have been published.
That will make life much easier for me. There are 7 summits where the details (name, height, location etc. ) are correct but the referrence got swapped/mixed/confused. The fix is to move the references about but everything else stays the same. Anyway, itās a little more involved as an index with unique constraint needs to be dropped before the swaps and rebuilt after. It works on my local copy but I want to be sure this is the best way to fix it before I push it to the live DB.
I suppose it depends on whether people logged against the name of the summit they climbed or the ref.
Iāve done this kind of thing before, and Iām guessing you donāt actually have to drop the index. The trick Iāve used is to manually add some constant to the numerical part of each set of summit references you need to change over or swap - obviously the constants will be different for each set or subset which needs to be changed, and have to be chosen so that the resulting sets will have summit references which not equal to (i.e. well above) any existing summit references. The index will purr along sweetly as you make the changes. Make the changes manually and then subtract the constants from each set of summit refs - ta da!
Thatās a cool idea and nice way to get around the unique constraint. I was reluctant to drop and recreate the index at first but then remembered the āScript Index asā¦ > Create toā¦ > New Windowā and it generates the fully qualified and complete t-SQL for you. Like this below, and it makes this kind of thing so easy. Itās what I really like about MS-SQL 'coz I certainly donāt like how much it costs to buy and deploy!!!
USE [mydatabase]
GO
/****** Object: Index [IX_Summits] Script Date: 21/11/2017 11:04:55 ******/
CREATE UNIQUE NONCLUSTERED INDEX [IX_Summits] ON [dbo].[Summits]
(
[SummitCode] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
However, your nifty trick is great when I need to do something in a hurry and donāt have access to MS SQL studio. It really is a nice bit of lateral thinking.
Yep, itās sure nice to have that MS SQL Studio. I often have to do things on the command-line with MySQL - especially in the newest, not-yet-live versions of the SMP and iotamaps, neither of which feature any kind of db GUI - and which doesnāt offer much in the way of automationā¦
The confused names/locations for 7 summits in W4C have been fixed. I had a chat with the AM, Pat KI4SVM, about this and heās telling me most people logged the correct refs. However, there may be a few in error.
So if you think your activator or chaser log is in error, then contact Pat in the first instance. Heāll help you get it fixed either directly or with some help from me.
Thanks for getting the summits straightened out Andy! I have just removed my cautionary notices from the summit info pages and will contacting the activators directly.