So, I have a SQL Server connection string that points at a local database:
Data Source=.;Initial Catalog=MyDatabase;Integrated Security=True
I cannot change this connection string, but I would love for the SQL server to live elsewhere.
Is there some way - either with SQL Server or with something in the Operating System to make this possible? I know that the Integrated Security (aka. Windows Authentication) part will make this really hard, but I figure it's worth asking in case there is a way.
If the client software uses the native SQL client (and almost everything does) you can alias any server name using the SQL Server Configuration Manager. In the Configuration Manager snap-in, expand the "SQL Native Client [version] Configuration" item, right-click "Aliases" and choose "New Alias..." There are two such items, for 32-bit and 64-bit, don't forget to add the alias to both places.
Use this power sparingly. Any server name includes special names like . and (LocalDB)\MyInstance, which normally refer only to the local machine and don't even use TCP/IP. Aliasing these can be very confusing to a casual reader. The alias is not case-sensitive, but it must otherwise match exactly, so adding blanks or using things like localhost instead of . will defeat it.
Related
My enterprise uses a company-wide management to all SQL Server instances, which causes all servers are named with similar name but hard to memorize their function, like
server_11001_sqlserver.company.com for development
server_11002_sqlserver.company.com for production
server_11003_sqlserver.company.com for another team production
server_11015_sqlserver.company.com for my team backup etc.
I need some way to clearly distinguish them such like building custom alias, which might be only visible to myself, in SSMS, to make development work easier. However, creating alias via configuration manager is not allowed for various reasons.
Are there any alternative ways?
create or delete a server alias in SQL Server by using SQL Server Configuration Manager.
Expand SQL Server Native Client Configuration in SQL Server Configuration Manager, click Aliases, and then choose New Alias from the context menu.
Type the alias name in the Alias Name box. Client apps connect using this name.
Enter a server's name or IP address in the Server box. A named instance's instance name should be appended.
Select the protocol that this alias uses in the Protocol box. The Port No, Pipe Name, or Connection String title of the optional attributes box changes when a protocol is chosen.
Programmers who build their own connection strings may find the connection strings provided in the SQL Server Configuration Manager Help to be helpful. Press F1 to retrieve this data in the New Alias dialog box.
I have been creating an access database for my assignment. I am using SQL Server 2014 for the datasource for the access tables. Now the problem is that according to the assignment
I need to make the db multiuser over network
it has to be an accde file
In short, how can I connect to SQL Server when I deploy the database on my college pc. And how to make the accde work on my school network where the SQL Server is not the one I am using at my personal machine.
It is a simple book entry database containing few tables including print button and picture of book attachment.
Use a DSN-less connection. Provide a function that changes the connection string on all linked tables.
See Linked table ms access 2010 change connection string
or Changing SQL connection information for DSN-less Access frontend
You don't want each user having to enter the server information into the frontend. So take your frontend to the school network, run the function to re-link all tables, then create the .accde, then distribute it.
If the sql server is on your same network, then all you have to do is link your tables to the production sql server. You then crate the accDE, and that can be deployed to any machine.
Access by “default” creates a DSN less connection. So if you follow the defaults when linking to sql server (use a FILE dsn), then once access links to those tables, access “converts” the DSN to a DSN less connection for you.
What this means is that you do not need any VBA re-linking code. When using a file dsn, access converts these to DSN less for you. Once linked, then Access ignores and does not use nor require the original DSN.
So your steps are:
Linking to the production SQL server on the network. Just make sure you use the “default” file dsn.
Once you are sure the accDB works with that production SQL server, you can then compile/create the accDE. That accde will now function on ANY workstation (and this work since access by default creates and uses and makes a DSN less connection for you).
You do NOT need any VBA re-link code.
You do NOT have to write some VBA code to create a DSN less connection (access does this automatic for you).
Of course, during this re-link process, your computer will have to be on the same network with the production SQL server you plan to link to.
If you were some off site worker, and you cannot be on the same network during the re-link process, then YES you would have to adopt some VBA code to re-link for you. However, if you can be on the same network during this re-link process, then at that point you can create the accDE file, and it can be distributed to any workstation on that network without further configuration.
About the only issue would be to ensure that you link to this production server using the standard and legacy “SQL Server Driver” as your linking choice. You can use the later “native 11” etc. drivers, but they are not installed by default on each version of windows and thus this ODBC driver may well not be installed on each workstation (but the standard SQL Driver is installed by default.
Again:
You do not need some VBA code or re-link code to create a DSN-less connection. Access by default when choosing a “file” DSN will create DSN-links for you – you thus don’t need any special re-link code, nor do you need some VBA re-link code to achieve DSN-less links.
I am a little confused about the pyodbc syntax. Basically I want to create a couple of functions to generate different strings configured for different authentication types; for pushing into pyodbc.
Here is a sample connect dialogue, and as you can see, I want to support Windows Authentication and SQL Server Authentication:
How do I programmatically generate these connection strings?
The connectionstrings.com page at
http://connectionstrings.com/sql-server-2008#sql-server-native-client-10-0-odbc-driver
lists several ODBC connection strings to accommodate the various options you might want to use. As for your comment...
I am not sure how to find my SID and other connection details for SQL server
...I'm not really sure what you intend to do, but knowing the SQL Server SID of any given user is unlikely to help you actually get connected to a SQL Server instance.
(It's also not terribly clear what Access has got to do with any of this....)
Each member of our development team has a copy of our application's database running on a local version of SQL Server 2008 Enterprise with SP1. Everyone is able to access the database by specifying their server and instance name in their web.config file, but to best share the developer version of our web.config file, we have standardized on making connections strings generic by using integrated security and setting server property to (local). This strategy is working fine for the majority of our 64-bit Windows 7 machines but in few cases (local) isn't recognized. We have compared settings via the SQL Server Configuration Manager (namely ensuring that the named pipes protocol was enabled) and we've tried setting the "(local)" alias via SQL Server Client Network Utility, but we haven't any luck. What needs to be done in order to use (local) in our connections strings?
Trying changing the Pipe Name for your instance to "\.\pipe\sql\query".
You can find that setting by starting SQL Server Configuration Manager, and navigating to SQL Server Network Configuration > Protocols for (Instance Name) and right-clicking on Named Pipes and selecting Properties. If Named Pipes is not enabled, be sure to enable it before restarting the SQL Server service (see comment by #NoahHeldman).
When connecting to the default instance (that is, without an instance name), SQL Server uses the default port of 1433 and the default pipe name of "\.\pipe\sql\query". Changing it back to match should (hopefully) fix it.
Those machines where the database connection as (local) doesn't work is probably that way because during the database installation, the instance name was set to something specific, rather than the default of "default instance". You can change these instance names, which may resolve this issue: http://coderjournal.com/2008/02/how-to-change-instance-name-of-sql-server/.
I think this occurs when you have SQL Server Express already installed and running, and then install SQL Server Developer Edition / Standard / etc....not 100% sure though, but from what I recall, that may be the case.
I have two development teams, that come from different groups.
Group A develops against a local default instance of Sql Server 2008 R2;
Group B develops against a local named instance of Sql Server 2008 R2.
Is there a way to setup an alias such that both groups are coding against the same name? As it stands right now we have a war of Connection Strings as group B changes (local) to ./DEV and group A changes it back again?
In SQL Server Configuration Manager, under the SQL server native client configuration section there is a subsection called "aliases" you can add an alias into here that points to your named instance. You just use the alias as if it is the default instance on a server with the name of the alias. We use this exact model and have only one connection string that points to a standard alias. Each developer has the same alias name pointing to their own instance.
Aliasing to a Local SqlExpress Instance
To expand on Ben's answer, I had the specific requirement to alias a connection string pointed at a specific Server Instance, and instead re-route this to our local developer Sql Express instances, i.e. to alias from:
SomeServer\SomeInstance
to
.\SQLExpress
This proved somewhat tricky until I found this link here. My Sql Express instance was running on the standard port 1433 (i.e. adapt to suite)
Enable TCP/IP for SqlExpress
Since aliasing is done via TCP/IP ports, TCP/IP protocol must be enabled. (Opening SqlExpress for remote access isn't necessary if you are working locally).
Using Under Sql Server -> Configuration Tools -> Sql Server Configuration Manager:
At the same time, set the Listen All property to Yes.
Enable LocalHost IP's
Ensure that both IPv4 (127.0.0.1) and IPv6 (::1) localhosts are active and enabled.
On each IP's, Leave the Dynamic Port at zero (as the name suggests, the port will be allocated dynamically). The IPAll Dynamic and TCP Ports are then used globally.
You'll need to restart the MSSQLServer / SqlExpress service to effect the change.
Creating Aliases (32 and 64 bit)
Under the Sql Native Client xx Configurations, this requires simply adding the alias "From" Server\Instance as the Alias Name and the actual server + instance as the Server (i.e. my local SqlExpress instance). I was able to connect via both port 1433, or the dynamic port on IpAll (9876), although saw no reason to use the latter. The aliases must be done for both 32 and 64 bit client configurations.
You should now be able to connect using the aliased SomeServer\SomeInstance via SSMS.
Other Notes
Since I was aliasing to a local instance, I did NOT have to add an alias for the from host, SomeServer to a DNS or LocalHosts. This will likely be required however if you are aliasing to a remote server (plus I guess some other security headaches)
I did not need to have the Sql Browser service running.
So it would seem that the Sql Client configuration takes care of the substitution prior to any network or security steps.
Personally, I'd make them all use the same box.
That said, you can set local aliases per developer's box using SQL Server Client tools.
Anything IP address or server name based (such as hosts file or DNS) will fail because instance names (and ports used) are different