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.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Arithmetic overflow error when user moves files

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!

Emily


Emily 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.

Go to Top of Page

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!

Emily


Emily Bersin
Go to Top of Page

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
Go to Top of Page
   

- Advertisement -