This is a continuation of an earlier question I had about moving the databases for a MOSS 2007 installation from SQL 2000 to SQL 2005. Here's the URL for the original question: Migrating MOSS 2007 from SQL 2000 to SQL 2005
In my test environment, I've successfully moved the databases to the SQL 2005 test machine and things appear to be working fine. But, on the "Servers in Farm" page of the Central Admin | Operations, it still shows the old (i.e. SQL 2000) server as the Configuration Database Server. Also, it shows the old config database as being the Configuration Database. I know that the SQL2000 server and old config database (that are showing on this page) are NOT being used, because we've deactived the SQL instance in SQL2000.
I've tried "removing" the server, and get a message about "Uninstalling SharePoint products and technologies" being the better route. So, I disconnected from the test databases, uninstalled SharePoint from the test WFE server, and reinstalled it. That didn't do anything. Before uninstalling/reinstalling I also tried simply rerunning the SharePoint Configuration wizard, and that didn't do anything either.
Does anyone know how to update the Config Server and Config Database on the "Servers in Farm" page after having moved the Config and Content DBs? Is there something I'm missing or overlooking?
Thanks.
stsadm setconfigdb
?
stsadm -help setconfigdb
shows:
stsadm.exe -o setconfigdb
[-connect]
-databaseserver
[-databaseuser ]
[-databasepassword ]
[-databasename ]
[-hh]
[-adcreation]
[-addomain ]
[-adou ]
Also see Technet which says PSConfig has superseded stsadm.
Hey, I completely understand your issue. YOu have moved your configuration database from the previous sql server to the new sql server. Let me make one thing very clear on this post that a configuration database cannot be moved to another sql server.
Hence, you need to run psconfig and disconnect from the current farm. Run psconfig again and create a new server farm. Once that is done, create new web application/applications and then attach the site content database/databases back to them. This is the only way to get your farm restored properly with the new sql server.
The best way we have found to do this is to use a SQL client side or DNS alias for the SQL server so that you can easily move the SP databases to a new server and just update the alias to point to the new one. In your case you could try the steps below, server names have been changed to protect the innocent. In this scenario you will need to have the same instance name (or use default) and possibly the same port.
Turn off SharePoint services
Rename the old SQL server from SQL2000 to SQL2000OLD
Create a DNS CNAME record called SQL2000 that points to new server called SQL2005
Detach/attach or backup/restore all databases from SQL2000 to SQL2005
Ping SQL2000 on SharePoint server to make sure that it resolves to SQL2005 and if not then run "ipconfig /flushdns" and repeat test until it resolves to new server
Bring SharePoint services back up, should connect to new server using DNS alias
Related
Our tool uses SQL Server 2012 LocalDB to store data. This as installed by the MSI, not full express. Users recently moved to new machines using other applications that connect via SQL Server 2019.
My understanding is that installing SQL Server LocalDB on top of an installation of SQL Server 2019 shouldn't cause an issue, being as how SQL Server Express installs as a named instance by default.
My concern when I look at connection strings, however, is that mine doesn't identify the server instance quite in the way I've seen recommended, only the Data Source:
Data Source=(localdb)\v11.0;Integrated Security=True;AttachDbFileName=C:\Database\Database.mdf;Connection Timeout=10000
This does connect, in case there's doubt. But referencing connectionStrings.com, I see recommended this:
Server=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyFolder\MyData.mdf;
In my mind, Data Source=(localdb)\v11.0 is already a clear designation of the instance, but I'm unsure what happens when SQL Server Express installs after SQL Server.
What should I look out for? Do I need to replace Data Source with Server? Will I need to change any part of (localdb)\v11.0 to account for the order SQL Server Express has been installed in compared with SQL Server?
EDIT 1
Updating the connection string by replacing 'Data Source' with 'Server' works. The question still remains, how will LocalDBs installing second affect what follows Server=?
We have an application called IpSwitch Whatsup and it's installed in a machine that I can connect to remotely as administrator. This is all in our intranet.
We need to connect to the sql server database being used by IpSwitch Whatsup, but this particular machine doesn't have sql server installed. On the other hand, in sql server configuration manager there is indeed a sql server installation for whatsup (the entry says SQL Server (WHATSUP)).
So, two questions:
How does one go about in connecting to this database? I'm pretty sure I know the name of the database and I already know the server name and instance, so I would like to connect to this DB from a sql server installation in another machine.
How does one configure a sql server installation to receive remote connections if it doesn't have sql server installed?
Thanks.
For the first question, you just type in (or browse) the appropriate instance name and authentication options using SSMS - which is the GUI tool used to manage sql server instances. Note - the term "sql server installation" can mean different things so it is not a useful reference.
As for the second question, review the information here. Note that any task you do in SSMS can be done via tsql - you can see the appropriate commands using the script button in the SSMS dialog windows.
And you can also (and probably should based on these questions) install SSMS on the same machine as your server instance so you can do "anything" "anywhere". Now would probably be a good time to review your disaster recovery options (and start backing up your databases regularly).
A couple of days back we moved our SQL Server database from a Physical server to a VM based server.
There were some reports in the reporting database which we skipped.
Now we cannot start the sql server instance on the old physical server, as the host name now points to the new vm based server in the DNS.
Can I just copy the reporting server database data and log files from the old server and attach them in the new server ? Would it work ?
Any help would be appreciated. Also if you can let me know of some steps it would be great.
Before doing anything backup your reporting services database and keys.
I would advice you to backup / restore the database to the new server rather than copying the mdf and ldf files. (report service must be stopped before restoring)
You should also export the encyption key from the old server and import it to the new server.
Also make sure to make the same customizations to the new report server configuration files if there are any (eg. custom dll permissions), copy custom dll's etc
By following the above steps you can make an SSRS database work on newer SSRS versions (I have tested restore an SSRS 2005 database to SSRS 2014 and 2016)
Read more:
https://learn.microsoft.com/en-us/sql/reporting-services/report-server/moving-the-report-server-databases-to-another-computer-ssrs-native-mode
I have been searching for directions and steps to rename a named server instance of SQL Server 2012. I have a rare opportunity to rename both the computer name and instance of the SQL Server. I stepped into a situation where all of the naming conventions need to be revamped. I'm assuming because I have no linked jobs or connections that I should be worried about, this will be okay. I have read that this isn't possible and others who say to use the sp_dropserver, sp_addserver but that doesn't work. Syntax would be helpful. My names are as such:
{machinename}\{instancename}
{COLO-VSR=SQLDW}\{SQLBISERVER}
I want to change it to {COLO-VSR-SQLDW}{SQLDW}
The "safest" way to do this is to (this does assume that downtime is possible for you):
Take a backup of each database (or, if you're going to install exactly the same version of SQL Server, including Service Pack level, detaching the databases is probably safe
Take the old instance offline
Rename the machine, including rebooting as required
Install the new instance of SQL Server
Restore the databases to the new instance of SQL Server
Validate
7. Uninstall the old instance of SQL Server
SQL Server has never seemed to handle renaming of the server it's installed on particularly well, hence the suggestion of creating a new SQL Server instance after renaming the machine. This may be better with newer, e.g. SQL Server 2016, versions but I suspect that "rename machine" is a scenario that doesn't get a lot of engineering priority or resource.
I'm trying to do some excercises from exam 70-515. Unfortunately I fail while trying to attach Northwind to a grid-control. It would result in:
NORTHWND.MDF' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported.
I use Windows 7 Home and MS Visual Web Developer 2010 Express. As fas as I understand this error, SQL Express must be an old version on my system. I downloaded and installed SQL Express 2008r2 from here. No effect. From other sources I figured out that I might need to change the instance name: Tools -> Options -> Database Tools -> Data Connections -> SQL Server Instance Name. There it is written SQLEXPRESS. I don't know what else I should insert there?
Turns out that deinstalling SQL Express and reinstall the latest version fixed the problem. I chose SQLSERVER2008 as Instance-Name while installing and set it in Visual Studio as described above.
Go to the Services control panel and look for a service named SQL Server (XXX) -- that XXX is the name of the instance that service is running. You just have to find the 2008R2 instance that you installed and type that into the "SQL Server Instance Name" box.
Might help to try to change the compatibility level, to make sure its backwards compatible.
Verify what level it is
USE VJ_DATABASE;
GO
SELECT compatibility_level
FROM sys.databases WHERE name = 'VJ_DATABASE';
GO
Then make it compatible with the older version
ALTER DATABASE VJ_DATABASE
SET COMPATIBILITY_LEVEL = 110;
GO
100 = Sql Server 2008
110 = Sql Server 2012
120 = Sql Server 2014
By default, Sql Server 2014 will change the db versions compatibility to only 2014, using the ## version you should be able to tell, which version Sql Server is.
Then run the command above to change it the version you have.
Additional step: Ensure you look at the accessibility of the DB is not reset, do this by right clicking on properties of the folder and the database. (make sure you have rights so you don't get an access denied)
I read this post but nothing helped me. Then I tried a few other options.
The way that I found that worked was to export the database and stored procedures from the original database. Then upload them into the second database(second computer).
Firstly export the DB content (data) - I used SQL server export data wizard. on the database you wish to export from right click then choose tasks, then export data. Follow the instructions and save in whichever format is best for you - I used excel for the data.
then to export the stored procedures rightclick the database name again. choose tasks and this time choose generate scripts. again follow the instructions of the wizard.
To import the data simply go to the second computer and right click the database you wish to import the data into. again tasks > import data. Follow the instructions to import all of the data from the database.
Finally to import the stored procedures, I opened up a new stored procedures command and dragged and dropped the script file that I had previously saved them in and dropped it into this window. The new stored procedure window filled with the entire list of my stored procedures. Finally change the name of the database name that will be used by the SP ( if this is different from the original DB name). (This is the first line USE [DBName]. then simply execute and the SP's will be fully restored.
This has helped me get my entire database up and running again very quickly. Hope this helps.
The SQL Management Studio is different than the SQL Server Version (or Database version). Example: At the current time, my work computer has SQL Server 2012 Management Studio but the SQL Version is 9.0 – which is SQL Server 2005. The SQL Management studio is only an IDE (Integrated Development Environment) and is NOT the same as the SQL Server version.
If when you try to Attach a Database, if you get an error similar to the following:
“The database 'AdventureWorks2008' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported.
Could not open new database 'AdventureWorks2008'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 948)”.
It means that the Database that you are trying to Attach was created with a Newer SQL version then what your computer has and you will NOT be able to use it. See if they have that Database that was created with the same or earlier version of SQL Server that your computer uses. In this case, I found the same Database that was created with SQL Server 2005 (Version 9).
A quick way to check what SQL Server version the computer is running, from the Windows desktop, go to Task Manager (Ctrl+Shift+Esc), click on the Processess tab, find and select the entry named “sqlservr.exe”, right click and choose Properties, click on the Details tab look at Product Version (Ex. 9….) or File Version (File version states the year and the version - Ex. 2005.9…).
Really this is the same error that i get, but until now i did not solve the problem!!
Go to Tools>Options>Data Connections, provided you have installed SQL Server Express 2008r2, leave the SQL Server instance name blank.
This happens when you are trying to use the SQLServer Express to connect to the MDF file. To remedy this issue, you need to go to Services.msc and turn on SQL Server services. You need to set the log on properties and when the service is started, you will be able to connect to the MDF file without any issues.