I've been making a first attempt to use fluent nHibernate on an ASP.NET MVC 3 application. Because I have multiple instances of SQL Server Express, I've been trying to specify a named instance along with the server while creating a session factory with the Fluently.Configure() method. My connection string for the database is of the format:
Server=myServerName\theInstanceName;Database=myDataBase;Trusted_Connection=True;
This causes an nHibernate exception reading:
Format of the initialization string does not conform to specification
starting at index 19
where the index given corresponds to the slash before the instance name. This connection string works fine with Entity Framework 4. So how am I to specify the named instance I want to connect to in nHibernate?
Since you are doing that in code, you must escape the \ either by doubling it (\\) or by using a verbatim string:
connectionString = #"Server=myServerName\theInstanceName;Database=myDataBase;..."
Otherwise, \t is interpreted as the tab character.
Related
I want to add serverless Synapse Analytics Studio to the linked services of Data Factory using Python. I want the authentication be done through system-assigned managed identity. The class I am using to define the linked service is AzureSqlDWLinkedService(), where I am passing the connection string as a string.
My connection string is in the ODBC format and looks as follows:
Server=tcp:<SYNAPSE WORKSPACE NAME>-ondemand.sql.azuresynapse.net,1433;Database=<DATABASE_NAME>;Connection Timeout=30
The problem is, the connection string details are getting passed as the additional parameters, while the required fields are still empty..
My guess is the parameters within a connection string don't match and therefore are getting passed as the additional ones. I am however keeping the same format as shown for the AzureSqlDWLinkedService class on this page:
https://learn.microsoft.com/en-us/azure/data-factory/connector-azure-sql-data-warehouse?tabs=data-factory#linked-service-properties
Grateful for any help!
I want to update database on Heroku using migration in ASP.NET Core.
I used correct connection string (DATABASE_URL), but when I run command
update-database
from Package Manager Console, I get message
Format of the initialization string does not conform to specification starting at index 0.
I'll leave my connection string format here:
postgres://odb...:5670...#ec2-54-243-54-6.compute-1.amazonaws.com:5432/2d...
I thought that DATABASE_URL format is good, but it's not, you need to use Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;,
PLUS in the end I passed two additional parameters: Sslmode=Require; and Trust Server Certificate=true.
I'm new to SqlServer, right now I have SqlLocalDb installed to work locally. Good, but I can see two connection strings typically and both works:
Data Source=(localdb)\v11.0;Integrated Security=true;
and
Server=(localdb)\v11.0;Integrated Security=true;
What exact difference is there between the two?
For the full list of all of the connection string keywords, including those that are entirely synonymous, please refer to the SqlConnection.ConnectionString documentation:
These are all entirely equivalent:
Data Source
Server
Address
Addr
Network Address
... There is no difference between Server and Data Source as they represent the same thing for SQL Server : the full name of the SQL Server instance with the syntax "MyComputerName\MyShortInstanceName" , potentially including the port used by the SQL Server instance to communicate.
Reference: http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/7e3cd9b2-4eed-4103-a07a-5ca2cd33bd21
They are synonymous - you can use either one.
That is - as far as the framework is concerned, they are the same.
My favorite set up is one that doesn't contain any spaces. In the simplest form, one has to provide four values - the URL, the container, the user and the credential.
server
database
user (or uid)
password (or pwd)
So a connection string looks like this.
server=stuffy.databases.net;database=stuffy;user=konrad;password=Abc123(.)(.);
I have a legacy VB6 app where the servername, databasename, username, etc are defined in an INI file, but the port number for the connection string (the default 1433) is hard coded in the app. It's being moved to a new sql server back end that runs off a different port number. I'm trying to avoid having to alter and recompile the application which entails signifigant retesting, documentation, etc. I tried altering the INI file so that for the new server I have put in: SERVERNAME\INSTANCE,NEWPORTNUMBER
This effectively builds the connection with Data Source = SERVERNAME\INSTANCE,NEWPORTNUMBER,1433;
This appears to work correctly as it connects to the database when I run the app. It appears to me that the ,1433 portion is being ignored. Is this a valid assumption or will this cause me some problem I'm not seeing here?
EDIT: The string way the connection string is built in the VB6 code is:
ConnectString = "Provider=MSDataShape;Trusted_Connection=Yes;Data Source=" & SERVER & ",1433;Initial Catalog=" & DATABASE & ";Data Provider=SQLOLEDB.1;Extended Properties=""Network=DBMSSOCN"""
with the SERVER & DATABASE values pulled from the INI file.
Port 1433 would normally override the INSTANCENAME. (MS blog Reference and another)
3 options I see:
The instance name is being ignored, and you're connecting to the default instance on port 1433
The named instance listens on port 1433
You have a client alias (not convinced about this one)
Can we see the code that creates the connection string?
Is there a network reason you need to use TCP/IP to connect to sql server?
My guess is that you just need to include a ; after the servername/instance name and just leave the port number out altogether. This will cause the port number to be extraneous data in the connection string. Which I think is just ignored. You can test creating an connection string yourself by creating a test.udl file and double clicking it - follow the wizard. After your done the connection string is in the udl file which you can view with notepad.
And of course if you are looking for the syntax for connection strings, you can look them up on connectionstrings.com
Download a free HEX editor
Save a copy of your original exe somewhere
safe
Open the exe in the HEX editor
Find the 1433 and change it to your
new port number
Once it works, you don't have to retest everything (like you would on a recompile)
If the new port number is not four digits it is trickier (path of least resistance: change it to a four digit port)
I have changed connection strings this way in the past.
A VB6 exe always uses DBCS so you may have to play with the hex editor until you figure out how to use the search feature in the right way.
If the port number is stored as an integer it may be trickier to find, but still possible (look for strings near it for your clues).
Apparently this app is quickly hacked together. Try to hack it back with a simple connect-string-injection like SERVER="{your_server},{your_port};FooBar="
I'm not sure that every library that uses the connection string would necessarily parse it the same way. I would think there could be one library that parses that connection string and just drops off the last port number and another that throws an error for an invalid port number perhaps. What libraries are using that connection string?
If you're using integrated security, then maybe you could set the Data Source in the INI file to say,
SERVERNAME,PORT; Password=
and let the SQL server ignore the Password key, which is unused with integrated security. That is if the code that constructs the connection string doesn't check for stuff like that. Oh, Will Rickards said this already also it seems.
A report needs to be run on multiple sites, each with its own connection string. These site names and connection strings are stored centrally.
I want to make a report that
Accepts the site name as a parameter
Queries for the sites connection string
Uses the sites connection string to get the report's data
I've tried using two data sources in the report, where the first data source uses the site name parameter to retrieve the connection string and the second uses an 'embedded connection' with a function for its connection string.
=First(Fields!ConnectionString.Value, "SiteDetails")
However when I run the report I get:
[rsFieldInQueryParameterExpression] The expression used for the parameter ‘SiteDataSource’ in the dataset ‘SiteDataSource’ refers to a field. Fields cannot be used in query parameter expressions.
Is there a way around this, to use a connection string from a database?
I am using SQL Server 2008 Reporting Services.
I have had this working in SSRS 2005 by storing the connection string in a hidden report parameter, then setting the connection string of the second query using that parameter.
I wrote a blog post about something similar a while ago, you might find it usefull - http://www.beakersoft.co.uk/2008/06/22/setting-a-data-source-at-runtime-on-sql-reporting-services/