We are working with the Entity Framework, and most of the developers have named instances of SQL Server 2008 R2.
The connection strings that EF uses look like:
<add name="MyConnectionString"
connectionString="Data Source=MyInstance\MySource;
Initial Catalog=MyDatabase;
Integrated Security=True"
providerName="System.Data.SqlClient" />
So the problem, for multiple developers, is that the data source is different for everyone.
Previously, I'd use an ODBC DSN to get around this problem, but according to this post that's not directly available.
Is there a way to set up the connection string so that everyone's different data source can be accessed?
We use aliases for that in our project. Every developer should create an alias with the same name (e.g. Entitydatabase) that points to his/her named instance, so the connection string can be the same.
You can create an alias in Sql Server Configuration Manager, inside the SQL native client configuration node. The best is to set it for both 32 and 64 bits (if you have a 64 bit server installed). Also make sure to enable the client protocols you want to use (e.g. TCP or named pipes) to get it work.
Finally, in the connection string simply use the alias name as datasource.
Related
I'm currently using SSIS in Visual Studio 2019 with deployment into a SSISDB Agent on SQL Server 2019. I do not have admin access to the Server.
I am trying to parameterize an ADO.NET Destination that connects to an AWS PostgresQL database. The connection string uses a 32 bit ODBC System based DSN ("DSN=SERVER" minus the quotes is the entirety of the connection string being used, when displayed in the parameter, it is only "SERVER" minus the quotes.)
The error I'm receiving is not a numbered error. It is "The connection string is not valid. It must consist of one or more components of the form X=Y". I know the connection string is working because I can preview the data when in the edit window of the ADO.NET destination and the Parameterized connection string is used, but when I try to run the system, it drops out as soon as the Execute phase starts.
Is there a way to send a parameterized Connection String to an ADO.NET?
I am trying to follow quickstart to setup SQL Server (not LocalDb version of SQLServer that comes with Visual Studio) as my data store. Looks like that two databases will be needed - one for configuration and the other for operation. But my problem is that I couldn't figure out what db names I should use. I created two databases using names I came up with and ran the scripts I downloaded from quickstart to create all the tables. Now, when I try to make connection, I think I will need to specify db names in my connection string, don't I? What should I use to replace the original connection string provide by quickstart - "Data Source=(LocalDb)\MSSQLLocalDB;database=IdentityServer4.Quickstart.EntityFramework-4.0.0;trusted_connection=yes;" ?
You can have one database for both. But in general I would keep the configuration part in memory if the number of clients is small. Why spend hours keeping the config in a database for just a few clients and resources?
Better to just keep the users and persisted grants in a database.
Here's my scenario. I have set up an instance of Postgres DB running in the Google SQL cloud. It's up and running and if I whitelist my local IP, I can connect directly with no issue.
I then have deployed a docker container (postGrest) which is a web server that connects to the postgres DB.
When I configured this on Google Cloud Run, it did have a drop-down option where I could specify DB connectivity and it says that, behind the scenes, it configures Cloud SQL Proxy for this connection.
The container allows environment variables to be passed in to specify which server, etc.
One required parameter is the DB_URI to the postgred instance. When running locally, it looks like this:
postgres://authenticator:mysecretpassword#localhost:5432/testdb
When I tried to configure this on the cloud version I tried using the IP 127.0.0.1 (The google cloud SQL proxy documentation says this is how you connect via the proxy). This didn't work.
I then tried using the public-ip assigned to the postgres DB....this didn't work either.
Does anyone know how to specify the correct connection string using this DB_URI format?
I am just going to add this as an answer rather than a comment since it's easier for readability and perhaps helping other users. Please don't feel encouraged to change the accepted answer.
By following the documentation provided by the OP, the final pattern for the URI became:
# Breaking lines for improved readability
POSTGRESS_URI=postgresql:///dbname
?host=/cloudsql/myprojectid:region:myinstanceid
&user=username
&password=password
&sslmode=disable
* dont forget to prefix the unix socket path with /cloudsql/
Any parameters can be used normally as in the example of sslmode.
Also, be aware that two important things are mentioned in the Cloud SQL documentation:
Note: The PostgreSQL standard requires a .s.PGSQL.5432 suffix in the socket path. Some libraries apply this suffix automatically, but others require you to specify the socket path as follows: /cloudsql/INSTANCE_CONNECTION_NAME/.s.PGSQL.5432.
In my case, the program I am using already adds as a suffix .s.PGSQL.5432, so I didn't need to add it to my URI.
Warning: Linux based operating systems have a maximum socket path length of 107 characters. If the total length of the path exceeds this length, you will not be able to connect with a socket from Cloud Run (fully managed).
Cloud Run does not support connecting to Cloud SQL using IP addresses. This means 127.0.0.1 will not work. Cloud Run uses Unix Sockets. You must use a connection string.
The Cloud SQL Proxy connection string looks like this:
myprojectid:region:myinstanceid
You can get the instanceid from the Cloud SQL Instance Details page in the console.
You will also need to add permissions to your Cloud Run service account to access Cloud SQL. You will need at least Cloud SQL Client.
It seems that some postgres client libraries don't support putting user and password parameters in the URL query params. I had problems with pq for Node.js and would get the error "no PostgreSQL user name specified in startup packet".
An alternative way of writing the connection string is as follows:
Breaking lines for readability:
postgres://db_user:db_password#
%2Fcloudsql%2Fproj_name%3Aus-central1%3Asql_instance_name
/db_name&sslmode=disable
It's like a normal TCP connection string, but you put the path to the Unix socket as the host, encoding the / and : characters. If the first character of the hostname is /, then the hostname will be treated as a filesystem path.
I am using Entity Framework Code First to create my database.
Here is the current connection string
"Integrated Security=SSPI;MultipleActiveResultSets=True;Pooling=false;Data Source=(localdb)\\v11.0;Initial Catalog=Inventory"
However this database is not visible when I try to attach it inside SQL Server Management Studio.
This is because the account that runs the SQL Server service would need to have access to my user folder in order to see it.
I tried giving this account access but had problems due to permissions of other things in my user folder.
Thus I thought I should perhaps specify a folder name for the database to be created in, but I am unsure on how to do this, and what other problems this approach may bring.
[Update]
I am now investigating setting the AttachDbFilename in app.config
this link is helpful however I aren't clear on how to set up |DataDirectory| for a winforms app.
[Update]
The following connection string works
<add name="ConnectionString" connectionString="Integrated Security=SSPI;MultipleActiveResultSets=True;Pooling=false;Data Source=(localdb)\v11.0;AttachDbFilename=c:\databases\MyDatabase.mdf;"/>
It would be helpful to know how to configure the path to be the same as the exe file location.
You may first use sql server management studio (ssms) to connect to your localdb instance (server name: (localdb)\v11.0, Windows authentication)
make a backup of your localdb database (right click db -> task -> backup)
then share the db backup file with other system.
I wound up placing the following in Main()
AppDomain.CurrentDomain.SetData("DataDirectory", AppDomain.CurrentDomain.BaseDirectory);
and the following in app.config
<add name="ConnectionString" connectionString="Integrated Security=SSPI;MultipleActiveResultSets=True;Pooling=false;Data Source=(localdb)\v11.0;AttachDbFilename=|DataDirectory|\MyDatabase.mdf;"/>
I've been trying for quite some time to use Entity Framework with our IBM Informix databases. Hours of searching has pointed me towards installing the IBM .NET Data Server Provider, which I have installed, however when I attempt to add a new Entity Model to my project I only have the Microsoft SQL Server Data Providers listed. Am I missing a step? Is this even possible?
I am not an expert on Windows or .NET; treat any comments I make with due caution.
Installing the .NET Data Server Provider is an important first step. You now have to make sure that you can use it to connect to the Informix databases you want to manipulate. There are several things you'll need to check here:
Is the server (meaning the Informix instance) configured to allow DRDA connections?
By default, it probably isn't.
If you're the DBSA (database system administrator), you'll need to check that you've enabled 'drsoctcp' connections on the system, and configured a server alias to use that connection.
If you're not the DBSA, you'll need to chat with your DBSA to get the relevant information.
Assuming that you have DRDA connectivity enabled at the server side, you then need to ensure you have an appropriately configured ... DSN? Your client code needs to be able to connect to the server.
There is no reason I'm aware of why it cannot be done. However, I don't know exactly how to guide you step-by-step through any of the above.
You might need to seek assistance from IBM Technical Support.
You would help everyone if you clarified which version of Informix (the DBMS) you have, along with the version information for the platform where it is running (whether Windows or Unix, and the o/s version information) - and which version of the Data Server Provider you are using (and which variant of Windows you are using it on).