I need to collect data from a SQL Server table, format it, and then put it into a different table.
I have access to SQL Server but cannot setup triggers or scheduled jobs.
I can create tables, stored procedures, views and functions.
What can I setup that will automatically collect the data and insert it into a SQL Server table for me?
I would probably create a stored procedure to do this task.
In the stored procedure you can create a CTE or use temp tables (depending on the task) and do all the data manipulation you require and once done, you can use the SELECT INTO statement to move all the data from the temp table into the SQL Server table you need.
https://www.w3schools.com/sql/sql_select_into.asp
You can then schedule this stored procedure to run at a time desired by you
A database is just a storage container. It doesn't "do" things automatically all by itself. Even if you did have the access to create triggers, something would have to happen to the table to cause the trigger to fire, typically a CRUD operation on the parent table. And something external needs to happen to initiate that CRUD operation.
When you start talking about automating a process, you're talking about the function of a scheduler program. SQL Server has one built in, the SQL Agent, and depending on your needs you may find that it's appropriate to enlist help from whoever in your organization does have access to it. I've worked in a couple of organizations, though, that only used the SQL Agent to schedule maintenance jobs, while data manipulation jobs were scheduled through an outside resource. The most common one I've run across is Control-M, but there are other players in that market. I even ran across one homemade scheduler protocol that was just built in C#.NET that worked great.
Based on the limitations you lay out in your question, and the comments you've made in response to others, it sounds to me like you need to do socialize your challenge within your organization to find out what their routine mechanism is for setting up data transfers. It's unlikely that this is the first time it's come up, unless the company was founded in the last week or two. It will probably require that you set up your code, probably a stored procedure or maybe an SSIS package, and then work with someone else, perhaps a DBA or a Site Operations team or some such, to get that process automated to fire when you need it to, whether through an Agent job or maybe a file listener.
Well you have two major options, SP and SSIS.
Both of them can be scheduled to run at a given time with a simple Job from the SQL Server Agent. Keep in mind that if you are doing this on a separate server you might need to add the source server as a Linked Server so you can access it from the script.
I've done this approach in the past and it has worked great. Note, for security reasons, I am not able to access the remote server's task scheduler, so I go through the SQL Server Agent:
Run a SQL Server Agent on a schedule of your choice
Use the SQL Server Agent to call an SSIS Package
The SSIS Package then calls an executable which can pull the data you want from your original table, evaluate it, and then insert a formatted version of it, one record at a time. Alternatively, you can simply create a C# script within the SSIS package via a Script Task.
I hope this helps. Please let me know if you need more details.
I am just starting to use the Enterprise version of SQL Server 2014. I am completely new to Integration Services and need to use it to call stored procedures asynchronously.
Is using SSIS different from using SQL Server Agent? I am aware of SQL jobs and agents to execute stored procedures asynchronously. Is there any other way to do it using SSIS?
What I really mean to ask is Is there any other way to use SSIS for asynchrnous execution besides this?
Also, Can I get guidance on how to start with it as I am completely raw with SSIS.
Yes. Just create your tasks (such as Execute SQL Task which can invoke stored procedures) in parallel. Make sure the arrows don't lead into each other. SSIS will invoke the tasks simultaneously.
I've written a stored procedure that takes 15 min when executed from Management Studio. When it's activated from Service Broker, however, after 4 hours it hasn't done even half of its work.
Are there known performance issues when running SPs from Service Broker? (Perhaps Service Broker runs the SP inside a transaction and Management Studio doesn't?)
I'm using SQL Server 2005.
Update:
It appears the problem was executing a stored procedure from another stored procedure. More specifically, I have a stored procedure which receives an operation (export or delete). This SP then calls the respective SP based on the operation (one has an ETL process, the other deletes data). Forcing recompile on these SPs seems to have fixed the problem. I wonder if SQL Server should make an action plan for each sub-SP though, independent of the SP that's calling them. In that case, no recompile would be needed.
I don't know about Service Broker, but for general stored procedure troubleshooting check out the suggestions given at this question. They helped me a lot to figure out some problems with my stored procedures.
You can take a look at what the stored procedure is doing with the WhoIsActive routine, you can acquire the query plan and study if there is any difference with the query plan when executed in Management Studio, you can experiment with the OPTIMIZE FOR hint to eradicate parameter sniffing...
(Parameter sniffing is that the query plan is generated differently when other parameters are supplied. Is Service Broker passing the same parameters to your SP as the ones you pass in Management Studio?)
Good luck and please post your findings here if you are unsuccessful.
What's the best way to know which stored procedure are currently running in a database.
I have a stored procedure which basically calls other 3 and passes them some parameters and these 3 stored procedures take a long time to complete... I would like to know which one is running...
Thanks
I think you can also use SQL profiler to get information in more detail.
Use Activity Monitor to detect what is currently running on your database.
The Command column might indicate which stored procedure is currently running.
To help you monitor whats stored procedure is running I would suggest creating a SQL Job to run those 3 stored procedures seperately as steps. That way you can place an email alert step in between them so that you know when each one has completed.
This shouldn't be too difficult to setup in SQL Server Agent.
EDIT: SQL Profiler is an option, but this will have an impact on performance as you will be monitoring the live database, plus you indicated that the stored procedures take a while to run so you would want those times to increase. IMO I think a simple email alert, or some other form of notification which could be built at the end of each stored procedure would be you best option.
e.g. An simple insert to a log file with a timestamp indication when each stored procedure has finished.
How can I trigger a stored procedure in SQL Server 2005 based on emails arriving in an Exchange inbox (with POP3/IMAP enabled)? I'd rather not use Windows Services if possible, and use the SQL Server functionality instead.
Exchange has Event Sinks which could write data to the DB.
Sample: http://www.codeproject.com/KB/cs/csmanagedeventsinkshooks.aspx
Doing thins using SQL Server somehow or a Windows Service would require polling for changes, which is less efficient; either you consume much resources through intensive polling or you have some delay until you notice a new message. The event sinks are basically invoked right away, and depending on the sink you can even influence the message.