Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
ebersin
Starting Member
3 Posts |
Posted - 2002-10-01 : 13:31:38
|
| One of our users, in the interest of saving space on the hard drive, moved the files of about 5 databases he no longer needed off the server without detaching them first. Subsequently, the databases showed up as suspect. After the server was rebooted a few times, I discovered that the Version column of the sysdatabases table has been set to NULL for the missing databases. The outcome of this is that you can't select that column from the database - you get the error [Microsoft SQL-DMO (ODBC SQLState: 22003)] Error 220: [Microsoft][ODBC SQL Server Driver][SQL Server]Arithmetic overflow error for data type smallint, value = 61412. I can't run DBCCs against master either (same error), and in EM in the database folder, I can't see anything other than master, model, msdb and Northwind. I know that TembDB and another user database are there because they're being used. I was wondering what the best approach to fixing this problem is, other than saving off the one important database and reinstalling SQL Server. BTW, it's SQL 7.0 Service Pack 1 on an NT 4.0/SP5 server. We were considering manually updating the version column in sysdatabases to 515, which is what it is for the rest of the databases. Advice would be appreciated - thanks!EmilyEmily Bersin |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-10-01 : 13:37:52
|
| DO NOT UPDATE THE SYSTEM TABLE DIRECTLY!!!!!That'll be the fastest way to ensure your other working databases stop working.The best advice I can give, because ultimately you'll probably have to do it anyway, is to detach the remaining databases, re-install SQL Server, and then re-attach the databases. There are instructions in Books Online as to how to do it, follow them to the letter.And smack the @#!@#%! who deleted the databases without detaching them first. Not only would that get him/her fired in many shops, it could open your company up to liability problems, depending on what data might've been lost. Count yourself very lucky you didn't lose all of your data. |
 |
|
|
ebersin
Starting Member
3 Posts |
Posted - 2002-10-01 : 13:52:10
|
| Yeah, that's what our best plan was. I was hoping there was a quick fix, but it's a production server and we don't want to break it any more than it already is. The user is actually the application owner and main support person and should have known better. The remaining database is still functioning fine so we're not in crisis mode at the moment. We haven't lost any data either - all those other databases had been copied to another production server permanently and these leftovers were no longer being used. Security here is still in it's infancy. Thanks for your amazingly quick response!EmilyEmily Bersin |
 |
|
|
hbz
Starting Member
1 Post |
Posted - 2005-05-20 : 15:53:34
|
| I just ran across this problem today, and what I had to do was drop the databases that weren't in use. I hope this helps anyone else googling for this problem!-- hbz |
 |
|
|
|
|
|
|
|