Usually backreving the database to an earlier version SP4 to SP3a, isn't the issue it's the reverse that is the issue going from SP3a to SP4. I would look at the SP4 release notes and see if there was any schema changes accordingly, that might not be present in SP3a that would cause you a bit of issue.
I would also backup and restore method of the database transfer. If you use the detach/attach method and move from SP3a to SP4, the database is upgraded ( I know this happens when you go from SQL 2000-2005) which also might cause you some issues. Again I would work it in a virtual environment ( how I do it here) and see. Z Edward Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP+I, ME, CCA, Security +, Network + [email protected] Phone:401-639-3505 -----Original Message----- From: Joseph L. Casale [mailto:[email protected]] Sent: Wednesday, March 04, 2009 3:51 PM To: NT System Admin Issues Subject: RE: SQl 2000 sp4 DB into SQL 2000 sp3a server Cool, I have a virtualized environment, but I was hoping to gain concrete knowledge as I am not versed in SQL by any means. Ill give this a shot :) jlc -----Original Message----- From: Phil Brutsche [mailto:[email protected]] Sent: Wednesday, March 04, 2009 1:27 PM To: NT System Admin Issues Subject: Re: SQl 2000 sp4 DB into SQL 2000 sp3a server Detach removes the database from original MS SQL instance, but it can always be re-attached. The only caveat I can think of is with regards to users in 2 different ways: 1) when you re-attach a database the user ID that re-attached is the DB owner. That may or may not cause a problem but something to be mindful of. 2) End-user accounts if your application uses database users for authentication - those are stored in the "master" DB of the SQL 2000 SP4 instance and won't transfer over automatically, regardless of whether you use the detach/reattach or backup/restore method. If you use detach/reattach you might end up having to redo those. BTW, the backup/restore method I'm thinking of is the one in the Enterprise Manager. If your application has it's own backup/restore procedure it would be best to use that for the backup. In my experience the application-specific backup/restore procedure will take care of point 2. I suspect you will want to ask some of your questions in a MS SQL-specific forum - SQL Server Central (http://www.sqlservercentral.com/) comes to mind. Don't you have a test environment for this application? Joseph L. Casale wrote: > Just asking as once I apply SP4 and attempt the migration I can't > undo this (other reasons). I know SQL versions sometimes perform > upgrades... > > On another note, I don't know sh!t about mssql, but I was going to > backup to a file, then restore from a file. Is the this detaching > method you speak of the same thing or what caveats occur between the > two methods? -- Phil Brutsche [email protected] ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
