Lynn,

Ive had to run these scripts seperately, as with our previous upgrade [historical issues].
(Upgrade stopped at M stating key conflict).

But it means Ive had to edit the Settings table manually.

Can you confirm the values in the settings table?
Version- 6.15.4.238
DBSeq - 000007L

Is that where I should be?

Thanks

M

I have now inspected the progress made by the update in detail and find that 7M failed at the following:

-- make spatial reference system a related field of spatial reference
INSERT INTO    dbo.IW_Column_Type_Relationship (
            IW_Column_Type_Key,
            Related_IW_Column_Type_Key,
            Relationship_Type,
            Entered_By,
            Entry_Date,
            System_Supplied_Data)
VALUES        ('SYSTEM0100000001',
            'SYSTEM010000000U',
            4,                        -- "required by" relationship type
            'SYSTEM0000000000',
            GETUTCDATE(),
            1)

For the simple reason that this record already existed in the database. I have now run all the successive scripts without error. Can I assume that my update is now stable?

Also I have looked in the help file, expecting to find a list of changes in the latest update, but there doesn't seem to be one. Oh wel, back to the release notes.

Thanks Mary

As far as I can tel, the last upgrade we ran was the one called Upgrade Kit for v6.14.4,  which I see included the 7M script, but as with Matt, after this most recent failed update, the Setting table was left with DbSeq set at 0000007L. I presume that this was how it was left after the previous update, which might explain why the updater tried to run 7M again.

After running all the scripts manually I have amended the setting table to Dbseq = 0000007X.

Everything seems to be running normally now and what I have seen of the changes so far look great.

There was one other thing. Currently I seem to be the only person here with the necessary priviledges to be able to run updates, although we have so far been unable to identify the difference between my login and my colleague's (who should also be able to do it). It appears that the difference is to do with machine permissions. When she ran the update on her workstation she was told she did not have sufficient access to perform the update and the process stopped. Later she ran it again, on her login, but my machine and this was the update which successfully did the UI upgrade but fell over on the 7M script. Just before it failed she had a dialog informing her that the Access database had not  been updated.

This message isn't very informative, so we don't know if we were told this beciase the Access Db should have been updated but wasn.t, or if it was never intended that this update would affect the Access Db and we were just being warned that there would be a discrepancy betwen the SQL & Access versions of the Db.

Could you please clarify this and let me know if there is a way of performing the Access Db update manually as we use it quite a lot and would like to be sure it is reliable.

Agreed. 

It WAS run against 6.14.5, albeit an upgrade that had to be done manually.

It does seem stable and I will edit the Settings table as identified. (now you tell me it seems obvious!)
With luck the next upgrade should work perfectly.....

Rob, There might be a difference between the primary installation computer and the clients and their relative permissions?
i.e Its not entirely dependant on the user login.  Just a thought.

As for the access database - after doing a clean upgrade series from 6.10 a couple of days ago, I started receiving the 'access dtb not upgraded' from the upgrade to 6.14.4.
I thought that it was now regarded as reasonably redundant which is why it didnt bother me then. 
But NOW you got me worried.
It would certainly be good to ensure that the two are maintained.

Thanks all for inputs.

M