August 11, 2008 at 2:50 pm
I started doing the steps in Paul's blog from June 11, 2008 and got to the 3rd bullet where I did the command sqlservr.exe -m from the correct folder.
The following error displayed: Your SQL Server installation is either corrupt or has been tampered with (SQL Registraty Version Not Same as Server). Please uninstall then re-run setup to correct this problem
Should I have the network person uninstall SQL2005 and reinstall it?
I restored the backup that I made to a test db and the data looks ok in the app, so I could restore the db, after sql2005 was installed again.
Any advice is greatly appreciated.
Julie
October 15, 2008 at 2:04 pm
I just last week did an upgrade to 2005 and encountered the same problem as you are having. i also used paul randals blog which corrected problems related to syscols but not sysobjects.
I open a ticket with microsoft and this is what and recieved two email responses.
EMAIL1
(
Root Cause (if known) – This is a known issue that occurs when a table has been deleted not using the established methods of deleting database objects (e.g. modifying the system tables). The error existed in SQL 2000 but was not checked by DBCC CheckDB. SQL 2005 began making this check in DBCC CheckDB.
Resolution – There are two supported options:
1. Ignore the error. Your database performance should not be affected by this.
2. Create a new database and move all data and objects to the new database.
)
EMAIL 2
(
Resolution – I have submitting this question to the dev team and here are the two possible work arounds to your problem.
1st
Bcp out all the data, fix up 2000 databases before upgrade to Yukon, and bcp in the data.
2nd one (unsupported)
Remove the column thru DAC connection when SQL server started in maintenance mode. After issuing “Delete sys.syscolpars where id = ” thru DAC, restart the server immediately. This will also leave a message in your error log every time you restart SQL Server.
)
The most viable option here for me is to use email 1 resolution 2 and although i haven't tried email 2 resolution 2. Either way i'll have to schedule downtime a month from now.
hope this helps
January 20, 2011 at 3:51 pm
..
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
February 28, 2017 at 9:59 pm
Probably below steps will give practical steps to find workaround.
http://thesqlstuff.blogspot.my/2017/02/dbcc-checkdb-failed-due-to-invalid.html
March 1, 2017 at 2:45 am
Please note: 9 year old thread.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 8, 2019 at 12:52 am
The reason of getting SQL error 8992 could be many. Check out various possible reasons of getting this error and step by step process to fix it.
https://www.systoolsgroup.com/updates/fix-sql-server-error-8992/
July 16, 2020 at 9:30 am
Hi,
Syskeys is an old and deprecated system table.
Every time you upgrade your database to a new sql server version, even without knowing you are doing it (restoring a backup in a newer version, for example), an upgrade process happens, making changes to the database and system catalog.
For some reason I haven't identified yet, the syskeys system table is sometimes left behind. Maybe a failed upgrade, maybe something else, I'm not sure.
In order to get rid of the inconsistency message, there is the need to make a very dangerous procedure, updating the system table sys.sysschobjs in order to change the syskeys type to 'U'. I'm not sure if I should describe the process public, it's a very dangerous process.
In the end, I have no idea about the exactly reason syskeys was left behind or if something else was missing from one of the database upgrades, but everything seems working and for safety reasons I haven't dropped syskeys
Kind Regards,
Dennes Torres
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply