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 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.
I'm considering using dba_CopyLogins (found On SQLsoldier Here, and refrenced in many migration related threads in dba.stackexchange ) to get the logins moved over as part of a migration from SQL 2008 R2 to SQL 2012.
Edit: Why not just use Sp_help_revlogin?
As I understand it (please correct if i'm wrong) sp_help_revlogin comes with a lot of caveats. It does not map the users to the databases, it does not copy over the passwords, it does not handle explicit permissions.. I'm hopeing to avoid using a script to transfer logins that results in me still having to touch 50+ individual logins one at a time.
Most of our user logins (possibly all, but i've not checked each one) are windows logins so maybe I'm making mountains out of mole hills.
I have some questions concerning how to use [dba_CopyLogins] properly, since comments on other user's questions have been unclear/ contradictory or did not address my question, and to call me an "Accidental DBA" would be being kind.
First: I'm migrating from sql 2008 R2 (box A) to Sql 2012 (box B). Is dba_CopyLogins meant to created/run on box A, or on Box B?
Second: #PartnerServer..is that meant to be the server where the logins exist?
Is this where I put the name of the linked server object?
Third: Box A and B are on different domains, does that matter?
Forth: Just looking for confirmation that this script will fail if a login already exisits with the same name. Will it faily only that login, or will the whole script abort?
I used, as in the comments sp_help_revlogin method.
You can read more about it here: https://support.microsoft.com/en-us/kb/246133
The script must run on box A and then stored procedure called.
The stored procedure will output script for recreating logins. When you run it on BOX b it will fail just on exsisting logins.
Different domains. Yes. It is a problem. It is a problem if you use integrated security and there is no trust between domains.
But, if you use integrated security and you have the same users in destination domain, with sp_help_revlogin you can adapt the script to map logins to destination domain. I used this method to align stuff.
Another issue is the default db. It will be lost and somtimes this is a problem for some applications (with bad configuration).
I used to run this script on source server and the results on destination server:
SELECT 'EXEC sp_defaultdb ''' + name + ''', ''' + dbname + ''''
FROM master.dbo.syslogins
WHERE [name] IS NOT NULL
AND dbname IS NOT NULL
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.
We have a classic ASP application that simply works and we have been loathe to modify the code lest we invoke the wrath of some long-dead Greek gods.
We recently had the requirement to add a feature to an application. The feature implementation is really just a database operation requires minimal change to the UI.
I changed the UI and made the minor modification to submit a new data value to the sproc call (sproc1).
In sproc1 that is called directly from ASP, we added a new call to another sproc that happens to be located on another server, sproc2.
Somehow, this does not work via our ASP app, but works in SQL Management Studio.
Here's the technical details:
SQL 2005 on both database servers.
Sql Login is authenticating from the ASP application to SQL 2005 Server 1.
Linked server from Server 1 to Server 2 is working.
When executing sproc1 from SQL Management Studio - works fine. Even when credentialed as the same user our code uses (the application sql login).
sproc2 works when called independently of sproc1 from SQL Management Studio.
VBScript (ASP) captures an error which is emitted in the XML back to the client. Error number is 0, error description is blank. Both from the ADODB.Connection object and from whatever Err.Number/Err.Description yields in VBScript from the ASP side.
So without any errors, nor any reproducibility (i.e. through SQL Mgmt Studio) - does anyone know the issue?
Our current plan is to break down and dig into the code on the ASP side and make a completely separate call to Server 2.sproc2 directly from ASP rather than trying to piggy-back through sproc1.
Have you got set nocount on set in both stored procedures? I had a similar issue once and whilst I can't remember exactly how I solved it at the moment, I know that had something to do with it!
You could be suffering from the double-hop problem
The double-hop issue is when the ASP/X page tries to use resources that are located on a server that is different from the IIS server.
Windows NT Challenge/Response does not support double-hop impersonations (in that once passed to the IIS server, the same credentials cannot be passed to a back-end server for authentication).
You should verify the attempted second connection using SQL Profiler.
Note that with your manual testing you are not authenticating via IIS. It's only when you initiate the sql via the ASP/X page that this problem manifests.
More resources:
http://support.microsoft.com/kb/910449
http://support.microsoft.com/kb/891031
http://support.microsoft.com/kb/810572
I had a similar problem and I solved it by setting nocount on and removing print commands.
My first reaction is that this might not be an issue of calling cross-server, but one of calling a second proc from a first, and that this might be what's acting differently in the two different environments.
My first question is this: what happens if you remove the cross-server aspect from the equation? If you could set up a test system where your first proc calls your second proc, but the second proc is on the same server and/or in the same database, do you still get the same problem?
Along these same lines: In my experience, when the application and SSMS have gotten different results like that, it has often been an issue of the stored procedures' settings. It could be, as Luke says, NOCOUNT. I've had this sort of thing happen from extraneous PRINT statements in the code, although I seem to remember the PRINTed value becoming part of the error description (very counterintuitively).
If anything is returned in the Messages window when you run this in SSMS, find out where it is coming from and make it stop. I would have to look up the technical terms, but my recollection is that different querying environments have different sensitivities to "errors", and that a default connection via SSSM will not throw an error at certain times when an ADO connection from a scripting language will.
One final thought: in case it is an environment thing, try different settings on your ASP page's connection string. E.g., if you have an OLEDB connection, try ODBC. Try the native and non-native SQL Server drivers. Check out what connection string options your provider supports, and try any of them that seem like they might be worth trying.
Example code might help :) Are you trying to return two tables from the stored procedure; I don't think ADO 2.6 can handle multiple tables being returned.
I did consider that (double-hop), but what is the difference between a sproc-in-a-sproc call like I am referring to vs. a typical cross-server join via INNER JOIN? Both would be executed on Server1, using the Linked Server credentials, and authenticating to Server 2.
Can anyone confirm that calling a sproc cross-server is different than doing a join on data tables? And why?
If the Linked Server config is a sql account - is that considered a double-hop (since what you refer to is NTLM double-hops?)
In terms of whether multiple resultsets are coming back - no. Both Server1.Sproc1 and Server2.Sproc2 would be "ExecuteNonQuery()" in the .net world and return nothing (no resultsets and no return values).
Try to check the permissions to the database for the user specified in the connection string.
Use the same user name in the connection string to log in to the database while using sql mgmt studio.
create some temporary table to write the intermediate values and exceptions since it can be a effective way of debugging your application.
Can I just check: You made the addition of sproc2? Prior to that it was working fine for ages.
Could you not change where you call sproc2 from? Rather than calling it from inside sproc1, can you call it from the ASP? That way you control the authentication to SQL in the code, and don't have to rely on setting up any trusts or shared remote authentication on the servers.
How is your linked server set up? You generally have some options as to how it authenticates to the remote server, which include logging in as the currently logged in user or specifying a SQL login to always use. Have you tried setting it to always use a specific account? That should eliminate any possible permissions issues in calling the remote procedure...