The specific issue is that I want a SQL Server to connect to an Oracle database and the Oracle database has a Virtual Private Database configured. I need to execute a static stored procedure to enable the VPD to see data. How can I configure SQL Server to fire a stored procedure upon connecting to a remote database? I figure if I can fire a local stored procedure, I can put the remote stored procedure call inside of that. The key is, I need the SQL Server to fire this as soon as it is done connecting to the remote database and before it tries to pass any other queries to it. I'm trying to avoid making the applications do it explicitly.
SQL Server does not offer a solution to my problem.
However, you can setup the service account to have a logon trigger to execute what is needed.
Create Trigger My_User.Logon_Trigger_Name
AFTER LOGON
ON SCHEMA
WHEN (USER = 'MY_USER')
BEGIN
--Do Stuff Here.
NULL;
EXCEPTION
WHEN OTHERS THEN
NULL; --Consume errors so you can still log on.
END;
Related
I have a SQL Server procedure which I want to call from an Oracle stored procedure and get the result. Then I need to do some processing on the data.
Can I create something like DB link to call the procedure? Or is there any possible way to do that?
I had this issue solved by contacting DBA and creating gateway then using DBMS_HS_PASSTHROUGH with db link assigned with username, password and database
Because I need to fill a view with dynamic data, I wrote a stored procedure to collect the data and use select from OPENROWSET('SQLNCLI','server=....;trusted_connection=yes','EXEC Stored_Procedure') as the view definition.
As far as I know you can't use variables in your view definition so that's why I choose this route.
The stored procedure collects data from a linked server source combined with native SQL Server data. The linked_server has the appropriate permissions setup for the remote user and can be successfully queried from outside SQL Server.
That works very well in a local context but when I try to use the view in a PostGreSQL foreign-table I get an ODBC error. The first errors involved the permission to execute the stored procedure by the caller's user account. After that I get stuck. It seems the connection with the server has sufficient access permissions but the OPENROWSET call to execute the stored procedure does not (no login_mapping exists).
However, if I change the SQL in the OPENROWSET command to a simple select statement (select * from db.schema.table) it works fine.
I tried to change the server in de OPENROWSET to a datasource to the local server itself, with the remote user to impersonate, but with no luck either. The same login_mapping error.
My guess is that this has something to do with the fact that the users security context is not the one used by the OPENROWSET command?
I have looked around a lot but was not able to find a solution. Can you help me?
I'm having a very strange problem with a fresh install I have of SQL Server 2008 Express edition (yeah it's a bit old now, but whatever). When I connect via SQL Server Management Studio, I can both read and edit data (update or insert), but when I connect via my web application's data access layer, which uses SqlConnection and SqlCommand to try and update and insert data in tables, no changes occur in the database. The strange thing is that the code runs as if no error had occurred though; no exceptions are thrown, and my update statement causes SqlCommand.ExecuteNonQuery to return 1, indicating that supposedly 1 row has been updated. However, it hasn't. The application can, however, read data from the database via select statements.
Does anyone have any idea what's going on here? I even tried tracing SQL Server using ExpressProfiler, and its output seemed to indicate that the update should have occurred:
exec sp_executesql N'UPDATE Match SET TicketsSold=#ticketsSold WHERE MatchId=#matchId',N'#matchId int,#ticketsSold int',#matchId=1,#ticketsSold=1234
go
Yet TicketsSold stays at the same value (123) it was at before, and does not update to 1234. Is there some kind of "silent" read-only mode SQL Server 2008 Express could be running in? I'm baffled as to why the database isn't being updated.
By the way, this is a proper SQL Server database I created in SSMS, not some attached MDF file that resides in the same directory as my web application. The database is not set to "read-only" in database options, and I'm pretty sure that the user that the web application is logging in as has read/write permission on the MDF file; it is logging in as the same user I am logging in as using SSMS - with integrated Windows security - and I am able to update/insert as that user via SSMS.
Thanks to shf301 in the comments - I was creating a transaction but forgetting to call .Commit before the end of the using block. :-D I put that in and now it works.
I'm trying to create table from view from remote server (calling procedure UPDATE_PROC), like this:
SELECT *
INTO table
FROM [remote_server\database].DATABASE.dbo.view
And it works perfectly.
Problem is, when I try to create a new job, which is calling the previously worked stored procedure UPDATE_PROC
exec UPDATE_PROC
It doesn't work and reports:
Executed as user: NT AUTHORITY\SYSTEM. The OLE DB provider "SQLNCLI10" for linked server "remote_server\database" does not contain the table ""DATABASE"."dbo"."view"". The table either does not exist or the current user does not have permissions on that table. [SQLSTATE 42000] (Error 7314). The step failed
So it seems to be same, but it isn't. What I'm doing wrong?
UPDATE:
Remote server is SQL Server 2005, job is on SQL Server 2008
I'm logged as sa user. Procedure is working always, job calling stored procedure never
Job isn't run as sa user, but I don't know which user and where should be defined to execute the job propery....
It seems to me that's a security issue. User under which the job is running doesn't have permissions to access table on the remote server.
If I want to return the user a web page and write to a log or word by word processing, should I use a stored procedure call from CLR in a new thread or just use sql triggers?
You can't make a SQL Server trigger run asyncronously. The best you could do is utilize SQL Server's Service Broker to execute a stored proc call.