March 23, 2006 at 1:43 pm
We are planning to upgrade our entire environment from SQL2000 to SQL2005 Standard and I have a couple questions:
1. If our developement servers are going to be running SQL2005 32bit and our production servers are going to be running SQL2005 64bit are there going to be any compatibility issues between them? We will be transferring tables and objects back and forth between them on a regular basis and will also perform db restores on the 64bit systems from .bak files created on the 32bit systems, and vice versa.
2. Our developement servers will likely be upgraded by way of an in-place upgrade to SQL 2005 but our production servers will be upgraded by doing a fresh install of SQL2005 and then restoring from backup or attaching a db. Are there any differences between an upgraded SQL2005 server and a freshly installed SQL2005 server that might cause incompatibility issues when tables or objects are transferred or backups are restored?
Thanks for any comments you can offer.
March 24, 2006 at 9:45 am
The simple answer to both questions is no. There is no different between databases on a 32-bit system from a 64-bit system. Also, the upgrade process from SQL2K to SQL2K5 is really an install/uninstall model. We do convert databases to the SQL2K5 format automatically. But you shouldn't run into any compatibility issues in either case.
March 24, 2006 at 9:50 am
Thanks for your reply. Does anyone else have any experience with in-place upgrades to SQL 2005? What are the ups and downs of doing an in-place upgrade? Thanks!
March 27, 2006 at 7:38 am
At a Microsoft Launch event I learned that the in-place upgrade has a remote possibility of failing partway through, at a point when SQL 2000 is broken and SQL 2005 is not yet operational. Even without this piece of information, you would expect to prepare for the upgrade by backing up everything on the server in case anything went wrong (power failure, disk failure, etc) during the upgrade.
Since you have to be prepared to reinstall everything on the server anyway, why not just go ahead and do it? Wipe it completely, reinstall the OS and all updates, then do a new install of SQL Server 2005. It may sound like more work, but if you do an in-place upgrade and have any issues later (even months later) you're going to have a nagging doubt that some lingering dll somewhere may be the culprit. If you don't have that doubt I'm sure whoever handles your hardware support will suggest it is a software issue.
But to answer your questions, I would not expect any compatibility issues arising from in-place upgrade vs fresh install, or from 32-bit vs 64-bit.
April 5, 2006 at 1:04 pm
xp_sendmail isnt supported in 64bit
April 5, 2006 at 1:17 pm
I was suggesting that the SQL server create some kind of artifact, such as text, log, or XML file, in a share visible to a unix/linux box. The "sendmail" I referred to was the Unix application that delivers mail. As I recall from 20 years ago, a modem connection could be configured to dial out to another modem at a specific phone number to deliver mail, but not respond to any incoming call. This would seem to meet the legal requirement for no outside connection.
Of course, the same functionality could be written to run on the server by anybody who can open a COM port and send "ATDT" to a modem. If you dug up a TRS-80 or TI-99 it would be easy. Or dug up a programmer who remembers how it was before everything was done for you.
September 28, 2008 at 6:46 pm
hi i m finding difficulty in attaching the sql server2005 databse 32 bit to sql server2005 64bit
the error is
TITLE: Microsoft SQL Server Management Studio Express
------------------------------
Attach database failed for Server 'HEXA-PC\SQLEXPRESS'. (Microsoft.SqlServer.Express.Smo)
------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.Express.ConnectionInfo)
------------------------------
Database 'SSUET' cannot be upgraded because it is read-only or has read-only files. Make the database or files writeable, and rerun recovery.
Could not open new database 'SSUET'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 3415)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.3042&EvtSrc=MSSQLServer&EvtID=3415&LinkId=20476
------------------------------
BUTTONS:
OK
------------------------------
plz help me as i m a starter:s
September 29, 2008 at 10:00 am
I've this problem too and the problem is caused by the user used to logon to service. When you install, normally you would use LOCAL SERVICE.
The user for it is configured to NT AUTHORITY\NETWORKSERVICE. This user doesn't have rights to attach DB.
Solution:
1) Open Tools Admin (into Start Menu of Windows) and run Services. Look for service named "SQL SERVER (SQL EXPRESS)" and stop it.
2) Double-click it and go to LOGON flap
3) You'll se clicked "THIS ACCOUNT" pointing to that user. Click onto SYSTEM ACCOUNT, then OK
4) Star this service again
you should now be able to attach the DB.... Hope this works for you...
September 29, 2008 at 10:15 am
thnx fo rthe post
but its nt working :s
i m using vista i did all the steps same but its nt helping please can u advice ne other method
:s
waiting for ur reply
September 30, 2008 at 2:02 am
Ah, okay... Have you installed SQL sp2 as you cannot/shouldn't run SQL unless you have SQL SP2(on vista - something about the compatibility). If you don't have SP2 on then I would recommend un-installing the SQL instance & compounds and then re-installing, then before you start the service or attaching DB install SP 2. Other than that I'm out of idea's...
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply