I have to move a production SQL Server database onto another server soon, and I'm keen to catch any little programs which have been written by hard coding the server name into them. I have only recently inherited the system, and there seem to be a lot of Excel files scattered around connecting in using ODBC connections.
My initial thought was to find something that redirected any SQL server requests for a particular database to the new server, but I'm not aware of any such beastie. Anyone know if such a thing exists?
Ideally, it should redirect at server level and log the source so that I can go and change it to point to the new one.
If the server name is hard coded, why not give the new server the same hostname? If it's listed in DNS set the TTL to a very low value now (2 minutes) and then when the changeover happens the downtime of moving the actual database files across will help smooth over the transition.
Alternatively you can be evil, turn the other server off and force people to fix their apps when stuff breaks - which method you choose is down to your sysadmin style.
The SQL Server Client Network library supports aliases and redirects, see How to: Create a Server Alias for Use by a Client (SQL Server Configuration Manager). The alias is global for the client machine though, meaning all applications on the client host machine will obey the alias redirect.
Related
I have SQL Server Express on a windows server. I have 10 people with MS Access 2016 on the local PCs. assuming that the db is very small and simple. What is the simplest way to connect to SQL Server? Will simple ODBC work? Do I need to enable remote access? TCP/IP? Pipes?
Yes, the basic concept here is to use linked tables. It not clear if before using SQL server, you were using Access in a mutlti-user mode.
The general idea here is you have a split database. So you have the application part or so called front end. This concept is really no different than say running word, or excel. These applications are installed on each workstation. But THEN the application can use some file.
So, in a typical multi-user Access applications, you have your application part installed on each machine (the front end).
Then you will typical place the back end file in some folder on the server. And then your front end will have linked tables to the back end.
If you adopt sql server for the back end? Then the setup is really the same as above. You have the front end application part that you install on each machine, and you have linked tables like before. The only difference is now your linked tables are pointing to SQL server.
So, yes you do have to enable TCP/IP for SQL server. You also have to decide if you going to use windows authentication for the users (that is windows logon). You can really only from a practical use case use windows authentication if you have a domain controller. (A computer that manages permissions to all your computers). If you are not sure or don’t have a domain? Well then you will need to create and use SQL server logons. Most often, you can create one logon/user for SQL server and have all of the access FE use this one logon. (so once again, you link the FE’s using the Access linked table manager, and you use + save this logon during the linking process).
As as a standard approach, how your application will work is really the same when using SQL server or not. In these use case examples, you use linked tables in the front end. In fact if you had a access back end, and now use SQL server for the back end, then all your forms and even the VBA code should work as before. There are often some “minor” changes to code that uses recordets, but the forms etc. should work as before.
ODBC is the simple and proven method.
Sidenote:
Consider the method using a script and a shortcut to distribute the frontend to the users as described in my article:
Deploy and update a Microsoft Access application with one click
I have an application that cannot be modified that connects to a SQL Server database using a hardcoded connection string with windows authentication.
I need to move the database to another server but as I cannot modify the hardcoded connection string - I am looking for something to act as a local connection that will then relay the query to the remote database and return the result back to the app.
The only other way I can see to do this is to upgrade from SQL Server Express and use database replication but that will be expensive option for what I need.
Can anyone suggest any software to do this or recommend an alternative method?
Thanks
Update:
The connection string also uses Windows authentication which will not work on the remote server.
If your workstations don't need access to the old server, you could perhaps solve this with DNS, using a cname record to point the old server name to the new. If you can't do this organization wide, you might be able to use entries in the hosts file on the impacted workstations.
I just saw this in the comments:
the database server is the same machine where the app runs (ie, 'localhost')
In that case, you want to figure out what the connection string is using, and the hosts entry should be able to accomplish this.
In old server you can define linked server, pointing it to new one and create queries to link to remote tables; you can use different credentials for it. You may get some performance problems (esp update statements may slow down).
We have a single SQL server hosting 2 instances. One instance just cannot be upgraded do to legacy software. A separate project is addressing that but is over a year away. The second instance can be upgraded, but there are thousands of Excel workbooks pointing to it for reporting purposes. So in short neither connection string can be changed at this time.
Is it possible to redirect a connection from one instance to another on a second server while keeping the connection strings the same?
I need a connection from SqlServer\Instance1 to stay on that instance while SqlServer\Instance2 goes to SqlServer2\Instance2
Creative solutions may work but need to be rock solid and maintenance light.
I believe what you may be looking for has something to do with tunnels. SQL server configuration manager > SQL Native XX.X Configuration. Here, you can specify alias for instances.
Go nuts!
Please keep in mind that you might need to get your network admin involved if both DNS name are being used at the same time. A local DHCP entry can help you come up with a proof of concept. This tunnel works for instances.
I'm new to SQL server and I have a question
I created a database on a SQL server local DB instance and then I copied the .mdf file of the database to a USB flash drive and I was able to open the database from a different user account'
So I want to understand why is it so? Does it mean that anyone can copy my database file and open it on their own server? And how can I secure that?
Thanks
Does it mean that anyone can copy my database file and open it on their own server?
Yes, as long as it's the same version of SQL Server. This is why it's critical to maintain control of a server running SQL Server and prevent unauthorized access to the file system or backups.
So I want to understand why is it so?
The same software uses the same format. Much like how an Excel document can be saved on one computer and opened on another, so, too, can a database. By default, SQL Server stores data in the easiest and most straightforward manner it can for best possible performance. Security of the data files is often a secondary concern as most SQL Servers physically reside behind locked doors and OS access is restricted to computer administrators with domain authentication.
If you're running SQL Server 2008+ Enterprise, you have access to Transparent Data Encryption which will encrypt the data files on disk. That doesn't prevent moving the database if you have full access to the original host system, but it does mean there are additional steps and it will be difficult to access the data by directly reading the data from the disk. Furthermore, you can also encrypt your backups (I believe SQL Server Standard and above supports this, I'm not sure about Express).
As far as Express LocalDB... your options are pretty limited. You can use NTFS level encryption, but that will impact performance as the DB engine is no longer aware that encryption is going on. Furthermore, anybody who can access the DB unencrypted would be able to access the DB files to copy, so you're not actually protected against inside attacks. You could also use BitLocker full disk encryption, but again, that will come with some I/O cost and, again, doesn't protect against inside attacks.
Finally, no matter what you do anybody with sa or dbo level access to the server will be able to read your data. You can choose to store only encrypted data in the DB, but that pretty much eliminates any advantage of using SQL, and your application would still need to store the means to decrypt it somewhere, which means someone could find your decryption key and work backwards from there.
If the server is a real production server and it's properly secured, people should be able to connect to the database (using the server name and the database name and some kind of authentication), but beyond that, no one except administrators should have any other kind of access to the server.
Specifically, no one but the administrator(s) should:
be able to see the .mdf file or the folder that contains it
have physical access to the server so that they are even able to plug in an USB flash drive
That's how it should be on a "real" server.
SQL Server LocalDB is a local-machine-only version of SQL Server Express for development.
So I guess that the machine you're talking about is a development machine.
But it doesn't matter if it's a production server or development machine - the following always applies:
Whenever someone has access to the actual physical machine, they will be able to copy the database files.
When someone has a copy of the database file, they will be able to restore it on another server and open it with an admin account, no matter what permissions you had set. An admin account will always be able to open it.
There's no way to prevent this, other than to make sure that evil people with USB flash drives will never have any kind of access to that computer, beyond remotely connecting to the database.
EDIT:
What about data encryption and special key?
I personally didn't know about it before, but there's already some information about it in the other answer - go read it.
TL/DR:
Moving the database becomes harder, but not impossible
Getting the data out of the database becomes even harder than moving
...but the OP isn't able to use it, because he's using LocalDB (=Express Edition), but Transparent Data Encryption is available in Enterprise Edition only.
I've seen lots of questions regarding moving data from Access to SQL Server, but I'd like to go the other route. Here's why:
I've been working on a sizable project with a SQL Server 2008 back-end and Access 2007 front-end. I'd like to be able to do some work on the front-end from home over the weekend, but I don't have access (VPN or otherwise) to SQL Server from there. I'd like to change my linked tables from SQL Server to another Access database file where I imported a snapshot of the SQL Server data. Then, come Monday morning, switch links back to SQL Server.
My problem is when I go to the Linked Table Manager and attempt to change the link, all I get is the ODBC Select Data Source dialog. If I try to link to an Access database, it tells me ODBC can't be used to link, import or export to another Access file.
One thought has occurred to me but I haven't tried yet; maybe someone could tell me if it's a good or bad idea: would I be able to delete the links, re-create them to the other Access file, and not lose any functionality in my queries/forms/reports?
My proposal would be to have SQLExpress (free) installed on your computer. You can then have all the data available on the machine. Create a publication on your main server, and have your local machine suscribe to this replication (if you don't need to save/synchronize the data changes done on your machine, you can stick to a basic 'snapshot' replication.)
You then just have to change your connection string from your network MSSQLSERVER to your localhost SQLEXPRESS server instance to have your app work.
If, for any reasons, you have to make changes to the database model while being off-line, you will then have to unsubscribe from the main server before making the changes on the local server. When you're back to the office, make sure that the same changes are done on the main server. My advice is to write your changes in T-SQL, save them in a file, and launch the file against the main server once you're back to work.
My opinion: don't work too much on weekends, or make sure your client is being billed for that.
For linking tables, you need to delete them and entirely and recreate them. Using the linked table manager to refresh ODBC links doesn't even work reliably when you're still using ODBC, as there is data cached in the table link definitions that doesn't get refreshed (e.g., if you change the number of columns in a SQL Server view, refreshing the table link with Linked Table Manager will update the number of columns, but you won't necessarily get an updateable view (assuming the original was updateable)).
But it's not clear whether or not you'll lose functionality or not. That all depends on how much of your application's logic is server-side, in SQL Server views and stored procedures. None of those will work if you link to a Jet back end.