At work we are trying to upgrade infrastructure and finally separate app servers and database servers. We would like to migrate our current SQL server DBs to a new database server, but we have many Excel spreadsheets around the office that have database connections and data sources that link to our current db server.
Finding all of those references would be a fairly monumental task. Is there any way to re-route all of these data sources without having to find and update each Excel file that is out there? We're not even sure that all of these use consistent drivers, some may be ODBC, a lot are definitely OLE, some may even use ADO.Net through Excel Macros.
Does anybody out there have experience with a situation like this? Any help is greatly appreciated.
Assuming the connection to the SQL Server in the excel spreadsheets made by DNS name and not IP, then the following procedure will do the work:
Setup the new server with a new host name, a new DNS record , like there's a standard new installation.
Move your data & configuration to the new server. remember to move logins and make sure they mapped correctly.
Change the name of the old server. Make sure the old name is not referenced by the DNS anymore.
Add new DNS record (A record) to your DNS server, referencing to the IP of the new server. (BTW, you can also use WINS/SQL Alias, and not the DNS server way)
Now, the old name is referenced to the new server IP. BUT, connections won't work in AD environment because of the Kerberos protocol. to make it work, assuming the server's new name is newname.ADDomain.com, and the service account of SQL Server is ADDomain\sqlsvc, run the following command on the SQL server: SetSPN -S MSSQLSVC/newname.ADDomain.com:1433 ADDomain\sqlsvc. if you're not in domain environment or not using windows authenticaiton you can skip this step.
After you done, clients will be able to connect the new server with the old name. I suggest that before doing this procedure you'll make sure you know how to do it and how to roll-back in case it's needed (which means, making sure you know how to get the old server up and running with the old name).
If you want to be on the safe side, and ready for future changes, you should consider making a little change: instead of using the old name as an alias to the new server, set up AlwaysOn cluster, and use this old name as the name of the listener, and not the name of the new DB server itself.
this way, future moves will be easier, as the clients will always use the listener name to connect and AlwaysOn will route them to the active server.
Hope this helps.
Related
Using the following:
MS Access 2016, Office 365
SQL Server 2012
I have 100+ SQL Server tables and views linked into an Access database via ODBC connection. All of these SQL Server objects are from two SQL Server databases that reside on the same server. All of these connections have been set up using the Access user interface and re-linked via the Linked Table Manager.
I've been experiencing a number of Access database issues lately, so I’m combing through everything with a fine-tooth comb. I noticed that the connection strings for all my SQL Server objects have a number of inconsistencies (see below). There does not seem to be any pattern in terms of when these objects where created and the format of the connection string either.
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2
Is it problematic that there are so many variations of the connection string? I've done some research (i.e., Googling), but I don’t much experience in this area of databases. Some connections have a "Network" specified, but others don’t. Per connectionstrings.com (https://www.connectionstrings.com/define-sql-server-network-protocol/), “Network=DBMSSOC” specifies a Winsock TCP/IP connection, which I believe is the appropriate choice for my network setup. Is it problematic that this parameter is excluded from several of the connection strings?
I would most certainly “harmonize” all of the linked tables to the same connection.
You can use the linked table manager to do this, but likely code is better.
You need to select all tables in the linked table manager, and MAKE sure you click on prompt for new location. This will force you to create (or select) an existing DSN. In fact, I would select all tables from the “one” given database, and then click on the “always” prompt for new location. When you do this, then all will posies the SAME link and connection string.
There are good number of reasons, one good reason is Access will cache the connection for you. So if you have “different” connections for the same database, you will have multiple caches of those connections. This likely will not affect performance “much”, but it still a good idea.
And if you are NOT using a trusted connection, then your connection strings in fact do NOT need to include the uid/password. (However, the cache of the uid/password requires exact string matches (minus the uid/password). In this approach, you can execute a “one time” logon on application start up, and then all linked tables (without the uid/password) will now work. However, you using trusted connections here, so this tip + issue don’t matter.
In your example, you using trusted connections, so issues are “much” less of a worry or problem.
I also STRONG suggest that when you launch the ODBC manager from Access, that you ALWAYS but ALWAYS use a FILE dsn. The reason for this is that then Access will convert the connections to DSN-less for you.
This means that you can now deploy the front end application to any workstation, and you don’t need to setup or have any DSN connection copied, or even setup on the workstation.
So I would in fact select all of the tables for one given database, (check the prompt for new location), and then create a FILE dsn (they are the default anyway). Once you link, then do the same for all the other tables that point to the other database. Again re-link.
The result will be a dsn-less connection, and thus your application will work on any workstation on the network, and do so without having to setup a dsn of any kind on each workstation.
So yes, you don’t have to, but it seems over time, some tables were linked using a different DSN, they should be harmonized. And if you ever introduce some automatic linking code, you want to be able to distinguish between the two databases, and you code will have a rather difficult time doing this with a “hodge” podge of differing connections.
So you can use the linked table manger to harmonizing the connections – just ensure you select all tables from a single given database, and then re-link with a FILE dsn, the result will be a DSN less connection (access will ONLY use the DSN during the linking process – after that, access don’t care, nor does it use or even look at the DSN, or even if it exists.
Having said all of the above, it not clear if this issue is related to your errors, or instabilities in your application. (a good idea is to always distribute a compiled version of your application - (a accDE as opposed to accDB).
I've been trying for a while to connect the database to visualstudio.net and it just doesn't work.
First I made the database and made everything I needed there and when I tried connecting it in visual.net through datagridview (trying to get it displayed there) it only gives me access to the "System databases" in which I can't make a database.
After that I decided to make the tables under the "master" database to see if that worked and yeah I can select the database and everything but it says it's empty when I know it's not. It says it has no tables when I've checked multiple times and saw the tables I've created there.
I would appreciate some help to either be able to get for visual to accept a database I make (to be able to automatically detect it once I enter the server name) or to see how can I use the master one properly.
You can add a data source to your project and it will be able to connect to the user databases. Also, it is highly inadvisable to create any user objects in the master database.
master database is a system database and you should not create user objects in the system database. In the connection string, provide the user database name explicitly. If you dont provide the database name, it defaults to master database.
Refer to connection strings for Sql Server for providing the right connection string for SQL Server in .net.
I have been experiencing random connection/handshake problems w/ a hyper server VM running SQL and SSRS
So the network guys suggested building a new VM and trying it there. (Have you tried rebooting? )
I asked that they rename the old server (--> SQLBKUP) and name the new server to the current name (--> SQL) so all my connection strings will continue to work.
Regardless the wisdom of that approach, that is all now done.
All of our applications work. (and the weird handshake issue is gone,joy)
I have reinstalled SSRS and I thought I was home free.
We backed up and restored the ReportServer and ReportServerTemp databases to the new server.
If i try to point to these databases , I keep getting this error
The report server installation is not initialized. (rsReportServerNotActivated) Get Online Help
Any all information I can find about this for 2012 says that the initialization happens automatically when you configure a database.
I tried creating a new database, and presto, everything works fine.
I reconfigured SSRS to point at the old database and I again get the rsReportServerNotActivated error.
I also 'powered down' SQLBKUP in case it was causing some confusion, I cant imagine what that might be, but why not... This did NOT correct the problem.
Any ideas on why the databases that were working on 1 server wont work on the new one?
Searching the interweb for this issue I find two results for 2012 SSRS (many hits for 2005 issues/resolutions )
this article details how the RSExec role should be configured, I have verified that is all correct.
https://msdn.microsoft.com/en-us/library/cc281308.aspx
this article details the mechanics of various ways to move a database. The back up and restore operations went off w/o a hitch.
https://msdn.microsoft.com/en-us/library/ms156421.aspx
neither article mentions cleaning up any server names, ip addresses, etc. that might be in a config table. Inspecting the tables in SSMS, I dont see any tables that look like they might need such attention.
I can always recreate the environment, I am aout to that point, at least I will know what I have in front of me. If anyone has any suggestions, i would appreciate it, Im sure I will be up for a while... :-)
tyia
greg
You are getting that error because you haven't moved the old encryption keys to the new server. SSRS uses encryption to secure credentials and connection information. You'll need to get the encryption keys from the old server and restore them to the new one OR if you don't have the keys anymore you can create new ones but you'll need to setup your connection information again.
First backup your old encryption keys:
Start the Reporting Services Configuration Manager, and
then connect to the report server instance you want to configure.
Click Encryption Keys, and then click Back Up.
Type a strong password.
Specify a file to contain the stored key. Reporting Services appends a
.snk file extension to the file. Consider storing the file on a disk
separate from the report server.
Click OK.
Then restore the keys to the new server:
Start the Reporting Services Configuration Manager, and then connect to the report server instance you want to configure.
On the Encryption Keys page, click Restore.
Select the .snk file that contains the back up copy.
Type the password that unlocks the file.
Click OK.
You can also use the rskeymgmt utility, see the MSDN article: Back Up and Restore Reporting Services Encryption Keys.
If you don't have access to the older server you'll need to delete and recreate the encryption keys. Once you delete the keys the server will automatically re-initialize itself and you'll need to re-enter all of the lost encrypted information.
The following things will occur when you delete the encryption keys:
Connection strings in shared data sources are deleted. Users who run reports get the error "The ConnectionString property has not
been initialized." Stored credentials are deleted. Reports and
shared data sources are reconfigured to use prompted credentials.
Reports that are based on models (and require shared data sources configured with stored or no credentials) will not run.
Subscriptions are deactivated.
Steps to delete the keys:
Start the Reporting Services Configuration tool, and then connect to
the report server instance you want to configure.
Click Encryption Keys, and then click Delete. Click OK.
Restart the Report Server Windows service. For a scale-out
deployment, do this on all report server instances.
This is from MSDN - Delete and Re-create Encryption Keys. The article has a lot more useful information.
For more information also read Configure and Manage Encryption Keys
I need to convert a named instance of SQL server 2005, to a default instance.
Is there a way to do this without a reinstall?
The problem is, 2 out of 6 of the developers, installed with a named instance. So its becoming a pain changing connection strings for the other 4 of us. I am looking for the path of least resistance to getting these 2 back on to our teams standard setup.
Each has expressed that this is going to be, too much trouble and that it will take away from their development time. I assumed that it would take some time to resolve, in the best interest of all involved, I tried combing through configuration apps installed and didn't see anything, so I figured someone with more knowledge of the inner workings would be here.
I also wanted to convert a named instance to default - my reason was to access it with just the machine name from various applications.
If you want to access a named instance from any connection string without using the instance name, and using only the server name and/or IP address, then you can do the following:
Open SQL Server Configuration Manager
Click SQL Server Network Configuration
Click Protocols for INSTANCENAME you want to make available (i.e. SQLExpress)
Right-click TCP/IP and click Enabled
Right-click TCP/IP and go to Properties
Go to the IP Addresses tab
Scroll down to the IPAll section
Clear the field TCP Dynamic Ports (i.e. empty/blank)
Set TCP Port to 1433
Click Ok
Go to SQL Server Services
Right-click your SQL Server (INSTANCENAME) and click Restart
This will make the named instance listen on the default port. Note : You can have only one instance configured like this - no two instances can have same port on the IP All section unless the instance is a failover cluster.
As far as I know, no. One reason is the folder structure on the hard drive; they will have a name like MSSQL10.[instancename]
This is why a lot of companies store their applications' connection strings at the machine level instead of the application level.
Just take the connection string out of the source code entirely. Then have everyone put their connection string in their machine.config.
This has the added benefit of avoiding unnecessary app-specific environment logic, i.e. when you copy your application to the staging server, the staging server already "knows" what database to use.
The only way to change the instance name is to re-install - uninstall and install as default instance.
A lot of times I'll use client alias to point an application at a different sql server than the ones it's connection string is for, esp. handy when working on DTS or an application with a hard coded connection string. Have everybody use a commonly named alias, use the alias in the connection string and point the alias’s on each dev box to the to the different instances. That way you won't have to worry about if the server is the default instance or not.
You shouldn't ever really need to do this. Most software that claims to require the default instance (like Great Plains or Dynamics) doesn't actually.
If you repost with your situation (installed X, then Y, but need to accomplish Z) I bet you'll get some good workarounds.
I think you can migrate your data from Sql Server without having default instance installed. You can just specify the port number of your Sql Server instance in Oracle Sql Developer and you can connect just using the server name, not using the server name and the instance.
Like this:
connect to "MYSERVER, 1433"
I need to connect and send/receive information from an MS SQL server in my Lotus Notes app using #formula in realtime (I can connect using an agent, but I need to use inline code for this).
The commands themselves seem pretty straight forward, but setting up the configurations seems to be a topic with scarce documentation. Apparently I need to install an ODBC driver. Where would I find that, and do I install that onto the server or onto the workstations that will run this app?
If any Lotus gurus could step me through setting this up, it would be greatly appreciated.
Thanks
You'll need to install the ODBC driver on the workstations that run this app, if the users will be triggering the ODBC connections. If at all possible, I highly suggest setting this up on the server side, and having it run via an agent. That'll save you from a few headaches, including having to maintain the ODBC connections on each workstation and worrying if each workstation has access to the data and server.
You first just want to make sure your ODBC setup is correct. You'll need the appropriate driver, of course, and the connection information. This site has a walkthrough to give you an idea of how to setup an ODBC database connection
If you have MS Access you can use it to test querying from the ODBC data source. Once you've tested the connection works, you'll just refer to the data source name (DSN) in your #DbColumn, #DbLookup, or #DbCommand formulas.
Back to my suggestion on setting this up on the server side, that would mean you'd keep a copy of the data you're querying within the Notes database itself, and then users would be interacting with read-only data in Notes. You could schedule updates regularly on the server side of that read-only data and effectively create a cache of the data in your Notes environment. Then that data would replicate around to other replicas of the database, but remove the trouble of the ODBC connection being needed everywhere.
If you need realtime data, though, that solution is out the window and you'll have to go with a local solution. In that case, you might want to look at the LCConnection class or using an ADODB.Connection from script, as both will allow you to create DSN-less connections to data sources. You'd then save the trouble of requiring ODBC data sources on each workstation, and only have to worry about whether they can access the server from their workstation.
I would add another option to Ken's list. It involves having the server do the queries of the external database (therefore you are only setting up ODBC in on the server - you don't have to deal with it on the workstations). You create an agent that is launched on the server using the 'run on server' technique. When the workstation needs to query the external data, the code creates a throw-away document in the database, puts the query criteria into the temporary document, saves the document, then calls the 'run on server' agent passing a reference to the temporary document. The server launches the agent, reads the criteria from the temporary document, does the query, and writes the results back to the temporary document. Then the workstation can access the query results from the temporary document. A scheduled agent can delete the temp docs on a regular basis.
It sounds complicated, and it all has to be done in script, but I've done this in many applications and it is fast, flexible, easy to administer, and gives your applications a lot of power. Note that end users must have the ACL rights to create a document in the db (the temp doc) in order for this to work.
Good luck!