Hi,
I have requirement that i need to Schedule package continuously(every 10 Seconds).
Any solution on this?
it would be great!
Duplicate post:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1037184&SiteID=1
sqlHi,
I have requirement that i need to Schedule package continuously(every 10 Seconds).
Any solution on this?
it would be great!
Duplicate post:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1037184&SiteID=1
sqlHi,
I have requirement that i need to Schedule package continuously(every 10 Seconds).
Any solution on this?
it would be great!
H there,
I'm afraid that 2005 doesn't give you the possibility to launch processes on seconds-basis, so you could do a little vb application where inside a loop and using a Timer..:
Dim pkg As New Microsoft.SqlServer.Dts.Runtime.Package
Dim EventsSSIS As Eventos
Dim app As New Microsoft.SqlServer.Dts.Runtime.Application
while true..
pkg = app.LoadFromSqlServer("msdb\yourpackage", Nothing, Nothing, Nothing)
sResultDts = pkg.Execute(Nothing, Nothing, EventsSSIS, Nothing, Nothing)
stuff..
Public Class Eventos
Implements IDTSEvents
OnPostValidate()
OnPreExecute()
..
stuff
|||HiI have two suggestions:
- you could reorganize your package to use an never-ending for loop, with a ~10 seconds sleep (I would try to do that first, if you have the possibility to modify the package)
- or use a scheduler (sql jobs, or third party software like nncron or cruisecontrol.net to trigger the package execution) - keep in mind that if you have to launch it every 10 seconds, it may end spending more time just starting and stopping compared to the time really used to carry out the transformations...
Thibaut|||
Sivarama wrote:
Hi,
I have requirement that i need to Schedule package continuously(every 10 Seconds).
Any solution on this?
it would be great!
Is SSIS really what you want here?
SSIS is inherently a batch tool. If you want something more real-time then perhaps BizTalk is what you're after.
-Jamie
|||Although you should have an "end process trigger", I would suggest using a for task, place all your stuff in it and just say while @.endtrigger = 0.
I have had a similar issue with trying to run things every 1 min, 10 sec is a little fast I think. On my server it takes an SSIS job 1 min 34 secs just to START the job. This makes it very hard to say, look for a file over and over, until it finds it.
We have a requirement to run profiler continuously to find out the
misbehaving applications/SQL in the dataserver. And we are not
interested in running it from an individuals local machine. Also we
want the profiler to start automatically whenever there are SQL Server/
Machine restarts.
Is there a way to invoke the profiler instance from cmd prompt or is
there a way to script the profiler?
Thanks in advance,
Thyagu.Here are the steps that can help you accomplish what you need:
1. Define your SQL Profiler Trace and script it. A good idea to place
restrictive filters to minimize the load on the production system. Make sure
the trace target is a file, not a table as it will have significant
performance impact. To script the trace use:
- SQL Server 2000 -File -Script Trace
- SQL Server 2005 -File -Export -Script Trace Definition
2. Modify the trace script and wrap it in a stored procedure. Add a couple
parameters to pass the target trace file, source database. etc. One of the
first statements in the generated trace script is calling sp_trace_create,
where you need to replace the target trace file as a parameter. And you can
add a call to sp_trace_setfilter (for example, EXEC sp_trace_setfilter
@.TraceId, 3, 0, 0, @.DbId) to set a filter for a specific database based on
database id that you can pass to the SP (or do not set that filter if you
want to trace for all databases). Also, the database can be one of the
preset filters in step 1 above.
3. Inside the stored procedure you can record the trace id to a table, so
later on if needed you can use the SP sp_trace_setstatus to stop the trace.
4. Create a job to schedule the stored procedure. In the schedule specify to
run automatically when SQL Server Agent starts.
BTW, this is the recommended way to run traces on production systems. If you
run a trace via the GUI you are actually running two traces: one that send
the trace to the target file, and another that sends the trace data to the
client running Profiler.
Regards,
Plamen Ratchev
http://www.SQLStudio.com