I have a 3rd party software which calls a stored procedure in my SQL Server to insert log entries. I would rather have the log entries write directly to a txt file instead of being in a SQL Server table.
I have tried collecting the entries in a ##temptable and using BCP to write them out but ran into an issue. The 3rd party software wraps all calls to the stored procedure in a transaction which causes BCP to hang during exports.
I thought about using a ##temptable and having a SQL Server Agent job dump it on a regular interval but the transactions can be long running and I'm not sure how to make sure I can write entries to the text files without duplicate or missing rows depending on transaction lengths.
Is there a good way to write from a stored procedure into a file? If so, is there a way to batch the writes over multiple calls of the stored procedure?
To access resources being out of SQL Server control from TSQL batch you can use a CLR Stored Procedure. With it you can write some .NET code to do anything you want with for example files or network connection. Then you have to prepare a DLL assembly and connect it with SQL Server. Here you are an example from MSDN how to create a procedure from external assembly:
CREATE ASSEMBLY MyFirstUdp FROM 'C:\Programming\MyFirstUdp.dll';
CREATE PROCEDURE HelloWorld
AS EXTERNAL NAME MyFirstUdp.StoredProcedures.HelloWorld;
EXEC HelloWorld;
More information about CLR Stored Procedures (and presented example) you can find on https://msdn.microsoft.com/pl-pl/library/ms131094(v=sql.110).aspx
Related
We are using a SAP HANA environment to connect to various databases (SQL Server, Oracle, Teradata). Now one of our sources (the SQL server one) contains a lot of stored procedures to calculate transient values. We would need to have these values as well in SAP HANA and are thinking about the best way:
Ideally, HANA can call the stored procedure of SQL and get back the result data, but I could not find information about this. Is this possible?
Another option is to write a little program (Java) in HANA that can call the stored procedure on SQL Server and then give back the data (either directly, or by storing is some temporary table on SQL side and then read in with HANA).
Other ideas?
Does anybody have suggestions on this?
As long as you can run SQL queries you could see if using OPENROWSET would work for you.
Using OPENROWSET with stored procedure as source you can then consume data as it would SQL rowset.
SELECT * FROM
OPENROWSET ('SQLOLEDB','Server=(local);TRUSTED_CONNECTION=YES;','exec master.dbo.sp_who')
AS tbl
Using SAP HANA Smart Data Integration (SDI) remote sources, you are able to access/federate to remote tables, views and stored procedures.
First create the remote source, then wrap the Stored Procedure in a Virtual Procedure, these can be created via the Web IDE or SQL. You would use the CREATE VIRTUAL PROCEDURE statement as described below.
Create Virtual Procedure with Web IDE
CREATE VIRTUAL PROCEDURE via SQL
I'm working on a fairly large application in which a database schema (tables, stored procedures, etc) is created by running a SQL script. The script is invoked from a stored procedure via xp_cmdshell like this.
CREATE PROC CreateNewScheme AS
BEGIN
...
EXEC xp_cmdshell 'osql createschema.sql -U username ...'
...
END
This stored procedure is run once during program initialization and again by SQL Server Agent during a scheduled job.
For security purposes we are required to disable xp_cmdshell. My first inclination was to just insert all of the schema creation commands into the existing stored procedure so it can be that can be executed as needed. However, this approach will not work because SQL Server does not support creation of stored procedures from other stored procedures.
One alternative might be to call the schema creation script from an external application rather than from a SQL script, but that's requires a fairly large rewrite, which we're trying to avoid if possible.
Is there a way to accomplish this with minimal changes?
My first inclination was to just insert all of the schema creation commands into the existing stored procedure so it can be that can be executed as needed. However, this approach will not work because SQL Server does not support creation of stored procedures from other stored procedures.
If you really need to wrap creation of stored procedures inside another store procedure you could wrap it with dynamic SQL:
CREATE PROC CreateNewScheme AS
BEGIN
EXEC('CREATE PROCEDURE myfirstproc AS ...');
EXEC('CREATE PROCEDURE mysecondproc AS ...');
END
Of course you will have to escape every ' inside dynamic SQL.
Another way is to exeute osql directly from SQL Server Agent job:
You should check if SQL Server Agent Account have sufficient privileges or create proxy.
EDIT:
If you cannot use SQL Server Agent, use Windows Task Scheduler to run osql:
Start Task Scheduler
Schedule a Task
We are in the same situation like you, whereby we want to disable xp_cmdshell, which we used for a couple of things on our production servers.
What we did was to create SQLCLR methods for the operations that xp_cmdshell performed in our environment. Sure, the assembly had to be created as UNSAFE, but the methods could only be called for the individual operations, and the methods had a lot of validation code, so that we didn't do anything "stupid".
I want to dump one SQL Server database - get all SQL code necessary to create a similar database. I have full online rights to DatabaseA, I can feed it with SQL and get the results back in rows in a table.
I do not have the possibility to use Enterprise Manager, any applications, utilities or the like. I can only feed it with pure SQL.
What I am after is SQL code, like CREATE TABLE and so on. So that I just can paste this into a query and voila - tables, procedures, functions are created in DatabaseB.
I will not copy the data.
This partly does what I want, it gives me procedures and functions:
Select object_Name(object_ID),definition from sys.SQL_Modules
But not for tables.
You can use the command line or you can create a stored procedure to create a back up, then use that backup to create a new database. I have used the command line often. Here is a previous Stack question that has a command line example and a link to a stored procedure example.
You can generate scripts in SQL Server Management Studio for an entire database or specific database objects.
To do this, right click the database then select Tasks then select Generate Scripts.
It will then open a wizard which will give you the option to choose to script the full database or just specific database objects.
i need to copy all the stored procedure and function at once from one sql server database to another.
is it possible than how?
In SQL Server Management Studio, go to the Object Explorer
Find your database
Right-click on it > Tasks > Generate Scripts
Pick stored procedures and functions as your objects to script out
Script them out to a file (or a bunch of files)
Run those files on your other SQL Server
Or if your two SQL Servers are on the same network, you could also use a tool like Red-Gate SQL Compare to just compare the structures and copy all stored proc and functions from your source server to your destination.
We are using ODBC from C on Linux. We can successfully execute direct statements ("INSERT ...", "SELECT ...", etc) using ODBC for both SQL Server 2008 and MySQL. We are migrating to stored procedures, so we first developed MySQL stored procedures. Calling MySQL stored procedures using ODBC works. Life is good.
The stored procedures are translated into T-SQL. We verify that they function by executing queries directly from Visual Studio. The database is filled, queries work. Huzzah.
We have a test program allowing us to use MySQL or SQL Server, direct execution or calling stored procedures. We call the T-SQL stored procedures from a C test program. Log output indicates that tables are being filled with data, queries are working, etc. Until the end, where a statement fails. The program exits (taking several seconds longer than normal). The other 3 cases work (direct MySQL, direct SQL Server, stored proc MySQL).
We examine the SQL Server database. It's empty. We have autocommit turned on, so I don't think it's a commit problem. The stored procs are bog simple, being copies of the direct SQL. Any ideas?
It sounds like the query is running - then errors out for some reason, and everything is wrapped up as a single transaction - and rolls back. Hence empty tables.
Does the stored procedure have any error trapping within it? SQL Server 2005 and later improved error handling enormously with TRY.. CATCH.