I have been given a task, which is the eventual re-write, but in the meantime, I need to document all that is going on.
We have an Access database that doesn't actually store any data. The Access database is simply the UI (MS Access Forms) that a user uses and the data is actually maintained in a SQL Server database. One thing I cannot seem to find is: the connection string used for MS Access to connect to the SQL Server. I need to find what database / server is used to store the information, but cannot seem to figure this out, nor has Google been able to give me the answers. Would anyone be able to help?
Open the Immediate Window (Ctrl+G)
? CurrentDb.TableDefs("a_linked_table").Connect
will give the connect string.
Or open a table in design view and open the properties.
you can run this query:
SELECT * FROM msysobjects WHERE connect <> '';
the result is the list of the objects with a connection string that is not empty.
Related
We use Azure SQL Database, and therefore had to jump through some hoops to get cross-database queries set up. We achieved this following this great article: https://techcommunity.microsoft.com/t5/azure-database-support-blog/cross-database-query-in-azure-sql-database/ba-p/369126 Things are working great for most of our databases.
The problem comes in for one of our databases which is read-only. The reason it's read-only is b/c it is being synced from another Azure SQL Server to derive its content. This is being achieved via the Geo-Replication function in Azure SQL Database. When attempting to run the query GRANT SELECT ON [RemoteTable] TO RemoteLogger as seen in the linked article, I of course get the error "Failed to update because the database is read-only."
I have been trying to come up with a workaround for this. It appears user permissions are one of the things that do NOT sync as part of the geo-replication, as I've created this user and granted the SELECT permission on the origin database, but it doesn't carry over.
Has anyone run into this or something similar and found a workaround/solution? Is it safe/feasible to temporarily set the database to read/write, update the permission, then put it back to read-only? I don't know if this is even possible - I was told by one colleague that they think it will throw an error along the lines of "this database can't be set to read/write b/c it's syncing from another database..."
I figured out a work-around: Create a remote connection to the database on the ORIGIN server. So simple, yet it escaped me until now. Everything working great now.
I'm trying to connect to a linked server from .net core.
I connect to my SQL Server, but I cannot reach the Oracle Database linked on it.
For example, I can connect to an actual SQL Server Database with the cnnStr:
"Server=foo\SQLEXPRESS;Database=DatabaseName;Trusted_Connection=True;MultipleActiveResultSets=true"
But if I change the Database parameter to the linked server, I get an error "Cannot open database "dbLINK" requested by the login. The login failed"
Does anyone knows how to connect to a linked database?
Thanks in advance
I believe the right way to do that is either creating views that access your linked server or access your linked server data directly from your query, for example, SELECT * FROM OPENQUERY([LINKEDSERVERNAME], 'SELECT Id, Name, Age from USER');
It`s important to point out that views are probably gonna be a better practice in this case. If you change anything related to your linked server in the near future, you'll need to change things in only one place.
Can I use OPENDATASOURCE (or another mechanism) from a Stored Procedure to connect to the same database as a different user? If so, how?
The database is meant to be deployed to several customers, and replicated by them as many times as they want to, etc. For this reason, I CANNOT HARDCODE the database server's name or the database's name.
(I tried using OPENDATASOURCE, but it only accepts hardcoded connection strings.)
Might EXECUTE AS work in your situation? http://msdn.microsoft.com/en-us/library/ms181362.aspx
You can set up a Linked Server to connect to the remote server using the login's current security context (or other options as it applies to your situation).
From your stored procedure, you could access it with something like SELECT * FROM mylinkedservername.mylinkedserverdatabase.dbo.mytable
But you say you want to connect to the same database but using a different login? You're looking for impersonation. Perhaps you can do this making a Linked Server that references itself, I haven't tried it. Search Microsoft Help documentation for how to set it up normally and test if it does what you're looking to do.
What am I missing here? The queries I see in SQL Server Profiler are all targeted against the master database, which makes it difficult to filter by database name ... which event or events should I be watching so I can filter by database name.
The bigger question, what exactly is going on here?
You should remove this 'MultipleActiveResultSets=True' from your EntityFramework connection
string
after that, you can see the target database name show in the Profiler , instead of master.
In my option, maybe ADO.NET team want to make use the MultipleActiveResultSets feature to get
data from DB, so they have to access master.
MultipleActiveResultSets is about raise one query and don't return all its result (like in foreach statement in LINQ) , and in the same time ,raise another query to get another data in the same session.
By default, this behavior is not allowed by DB. SO.....
I was able to get around this issue, including leaving MARS active by adding an application name to my connection string:
Data Source=database_server;Initial Catalog=MyDatabase;Trusted Connection=true;MultipleActiveResultSets=True;Application Name=MyDatabase;
Then you can filter on application name.
If this is for SQL Server 2008 R2, in your trace properties, on the 'Events Selection' tab, check 'Show all columns'. You should then be able to create a column filter based on DatabaseName.
I believe you'll have to pause or stop your trace to make these changes.
As K Ivanov pointed out, having MARS (MultipleActiveResultSets) enabled will show the DatabaseName as master in SQL Profiler. By setting this to false, it'll show the proper DatabaseName, but then you lose the ability to have MultipleActiveResults.
you can use LoginName or HostName to filter in the profiler
For some reason, if I select the SP:CacheHit event, it now shows the queries against the correct database and I am able to filter by it. What is that event exactly?
Every SQL Server connection string I ever see looks something like this:
Data Source=MyLocalSqlServerInstance;Initial Catalog=My Nifty Database;
Integrated Security=SSPI;
Do I need the Initial Catalog setting? (Apparently not, since the app I'm working on appears to work without it.)
Well, then, what's it for?
If the user name that is in the connection string has access to more then one database you have to specify the database you want the connection string to connect to. If your user has only one database available then you are correct that it doesn't matter. But it is good practice to put this in your connection string.
This is the initial database of the data source when you connect.
Edited for clarity:
If you have multiple databases in your SQL Server instance and you don't want to use the default database, you need some way to specify which one you are going to use.
Setting an Initial Catalog allows you to set the database that queries run on that connection will use by default. If you do not set this for a connection to a server in which multiple databases are present, in many cases you will be required to have a USE statement in every query in order to explicitly declare which database you are trying to run the query on. The Initial Catalog setting is a good way of explicitly declaring a default database.