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
Related
I have a database server out there - lets say the url is "the.database". It has several databases on it - db_a, db_b, db_c - that all require different users and passwords.
I can happily link to one of them like this:
exec master.dbo.sp_addlinkedserver #server='the.database' #srvproduct='SQL Server'
exec master.dbo.sp_addlinkedsrvlogin #rmtrvname='the.database' #useself='false'
#rmtuser='user_a' #rmtpassword='password_a'
select top 10 * from [the.database].db_a.dbo.some_table;
And that works great. For one of them.
However - what I want to do is connect to the server simultaneously with three different logins, and I can't figure out how to do it... in fact - what I'd really like is three different linked servers - db_a, db_b, db_c - which all actually point to the.database.... but if you use "sql server" as the product, it seems like the internal server name has to correspond to the url of the actual server? In the perfect world, I'd love to end up with being able to do:
select top 10 * from [db_a].some_table
where db_a actually means database dba schema dbo on server the.database.
So basically - is there a way to create a linked server with an internal name that doesn't match the external url? Or is there another way of solving this problem?
We are running SQL Server 2016. For in-house political reasons, I can't restrict access the way I want to. Assume that I can't change the premise.
We have a user that is used in SSIS packages. Unfortunately, some devs are logging directly into the db with ssms using this user. I need to prevent this without changing the password or something. What I need is to be able to allow a user access to the database ONLY if it is running from an SSIS package and NOT if it is coming in any other way.
I am not looking for other suggestions of how to fix this issue. I understand most of them already, I am stuck because of management decisions that I cannot change.
Can anyone tell me how to restrict a user in such a way?
An approach is to use a LOGON trigger
A first blush approach might be to reject any process that look's like the SSMS application
CREATE OR ALTER TRIGGER logon_developer_check
ON ALL SERVER
FOR LOGON
AS
BEGIN
IF (ORIGINAL_LOGIN() = 'triskydeveloper'
and EXISTS
(
SELECT
*
FROM
sys.sysprocesses AS S
WHERE
S.spid = ##SPID
AND S.program_name LIKE 'Microsoft SQL Server Management%'
)
BEGIN
ROLLBACK
END
END
But developers, being devious little buggers, will then write their own .NET application or use SQLCMD so you'd fall into a rat race trying to identify all the program_names that might show up.
I would instead look at the hostname column on sys.sysprocesses - if the connection isn't coming from the server itself, just reject it. Unless you have to deal with developers able to RDP onto the server.
Oh and if you mangle the logon trigger and it's rejecting everything, use SQLCMD and the dedicated admin console, DAC, and
sqlcmd.exe -S localhost -d master -Q "DISABLE TRIGGER ALL ON SERVER" -A
I have been tasked with comparing two oracle schema with a large number of tables to find the structural differences in the schema. Up until know I have used the DB Diff tool in Oracle SQL Developer, and it has worked very well. The issue is that now I need to compare tables in a user that I cannot log into , but I can see it through the other users section in SQL developer. The issue is that whenever I try to use the diff tool to compare those objects to the other schema it does not work. Does anyone have any idea how to do this? It would save me a very large amount of work. I have some basic SQL knowledge if that is whats needed. Thanks.
If you have been GRANTed permissions in that other schema, issue an
alter session set current_schema = OTHER_SCHEMA_NO_QUOTES_REQUIRED;
the run whatever tool.
Otherwise, it's select * from all_tables where owner = OTHER_USER;, 'select * from all_indexes where ...` etc.
Just reviving this question with a correct answer.
If you can get your DBA to grant you proxy through you can do the following without knowing the password of the end schema:
ALTER USER {use you do not have pw to - lets call it ENDSCHEMA} GRANT CONNECT THROUGH {user you have pw for - lets call it YOURSCHEMA};
Then you create a connection in SQL Developer where:
username: YOURSCHEMA[ENDSCHEMA]
password: YOURSCHEMA password
Then you can proceed and do a Database Diff on both schemas and never knowing the password for ENDSCHEMA.
FIRST You have to launch
ALTER SESSION SET CURRENT_SCHEMA = SCHEMA;
BUT ALSO IN THE FIRST SCREEN OF DIFFERENCES TOOL YOU HAVE TO CHOOSE FOR DDL COMPARISON OPTIONS - SCHEMA - "MANAGE" (NOT CONSOLIDATE)
(I have Sql Developer with italian interface, so I translated the options, the names could be a little different)
It works for me
Easily compare every things in two or more schemas using toad for oracle as in this pics
Step 1:
Step 2: compare window will appear to add schemas you want to compare (by default connected schema will be the one above) then click next,
Step 3: select objects you want to compare in both schemas then run
I have a weird problem here.
In short to the environment we have:
There is a (newly set up) Win2003 Server with a SQL Server 2005 Express database. I connect to it via a MS Access application.
Since I switched to the new server (restored a backup from the former server on it) all SPROCs (only in Access) have a ;1 after their name, hence cannot be found.
If I try to open a SPROC in Access (dbl click in overview), it asks for the parameter, then says cannot be found.
If I try to open, say, a report based on it, same result. If I change the name of the SPROC the report is based on to the name shown in the overview ( [sprocnam];1 ) it says "cannot be found" (of course, because the names did not change as one can see in Management Studio).
?!?
keep in mind that the Access-application worked fine with the database that I backed up on another server and restored to the newly set up server ...
Your help is greatly appreciated!
edit: I found a thread on SAP.com with someone experiencing the same problem, but without a solution: https://forums.sdn.sap.com/message.jspa?messageID=7947957
I can't tell why you have got this issue, but in In SQL Server you have the ability to create Numbered stored procedures. The procedures have the same name but may contain completely different code, look at this:
CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT ##MICROSOFTVERSION
END
GO
CREATE PROCEDURE [dbo].[spTest];2
AS
SELECT ##version
GO
EXEC spTest;1
EXEC spTest;2
I resolved the issue with an update of the clients office-installation to the latest service pack.
The one employee that notified me of the problem and me got new computers last week, and thus did not have the latest updates.
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...