Is there any way to send several ADO Command.Execute asynchronously at once?
Please reply. Thanks in advance.
Regards,
Hyun-jik BaeIn the following example, an event handler has been implemented to print to
the Debug window when the command has completed:
Dim WithEvents conn As ADODB.Connection
Sub Form_Load()
Dim cmd As ADODB.Command
Set cmd = New ADODB.Command
Set conn = New ADODB.Connection
conn.ConnectionString = _
"Provider=SQLOLEDB;Data Source=sql70server;" _
& "User ID=sa;Password='';Initial Catalog=pubs"
conn.Open
Set cmd.ActiveConnection = conn
cmd.Execute "select * from authors", , adAsyncExecute
Debug.Print "Command Execution Started."
End Sub
Private Sub conn_ExecuteComplete(ByVal RecordsAffected As Long, ByVal _
pError As ADODB.Error, adStatus As ADODB.EventStatusEnum, ByVal _
pCommand As ADODB.Command, ByVal pRecordset As ADODB.Recordset, _
ByVal pConnection As ADODB.Connection)
Debug.Print "Completed Executing the Command."
End Sub
Hope you mean ADO not ADO.NET ;-) For further information look in MSDN
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Bae,Hyun-jik" <imays@.NOSPAM.paran.com> schrieb im Newsbeitrag
news:eHtTcykRFHA.3988@.tk2msftngp13.phx.gbl...
> Is there any way to send several ADO Command.Execute asynchronously at
> once?
> Please reply. Thanks in advance.
> Regards,
> Hyun-jik Bae
>|||Thanks for your answer.
However, I found that the secondary asynchronous Execute fails while the
first asynchronous Execute is not completed yet. Is this phenomenon
ordinary? Or is there any way to enable more overlapped Execute be allowed?
Thanks.
Regards,
Hyun-jik Bae
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote in
message news:OfiXV1kRFHA.3156@.TK2MSFTNGP15.phx.gbl...
> In the following example, an event handler has been implemented to print
> to
> the Debug window when the command has completed:
> Dim WithEvents conn As ADODB.Connection
> Sub Form_Load()
> Dim cmd As ADODB.Command
> Set cmd = New ADODB.Command
> Set conn = New ADODB.Connection
> conn.ConnectionString = _
> "Provider=SQLOLEDB;Data Source=sql70server;" _
> & "User ID=sa;Password='';Initial Catalog=pubs"
> conn.Open
> Set cmd.ActiveConnection = conn
> cmd.Execute "select * from authors", , adAsyncExecute
> Debug.Print "Command Execution Started."
> End Sub
> Private Sub conn_ExecuteComplete(ByVal RecordsAffected As Long, ByVal _
> pError As ADODB.Error, adStatus As ADODB.EventStatusEnum, ByVal _
> pCommand As ADODB.Command, ByVal pRecordset As ADODB.Recordset, _
> ByVal pConnection As ADODB.Connection)
> Debug.Print "Completed Executing the Command."
> End Sub
> Hope you mean ADO not ADO.NET ;-) For further information look in MSDN
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "Bae,Hyun-jik" <imays@.NOSPAM.paran.com> schrieb im Newsbeitrag
> news:eHtTcykRFHA.3988@.tk2msftngp13.phx.gbl...
>|||There should be the possibility to do this unless you will not use the same
connection for it.
Jens Suessmeyer.
"Bae,Hyun-jik" <imays@.NOSPAM.paran.com> schrieb im Newsbeitrag
news:uCgnSElRFHA.2736@.TK2MSFTNGP09.phx.gbl...
> Thanks for your answer.
> However, I found that the secondary asynchronous Execute fails while the
> first asynchronous Execute is not completed yet. Is this phenomenon
> ordinary? Or is there any way to enable more overlapped Execute be
> allowed?
> Thanks.
> Regards,
> Hyun-jik Bae
> "Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in message news:OfiXV1kRFHA.3156@.TK2MSFTNGP15.phx.gbl...
>
Showing posts with label asynchronously. Show all posts
Showing posts with label asynchronously. Show all posts
Thursday, March 22, 2012
Asynchronous ActiveX Replication Problems
Hello,
I have a VB.NET service that has a timer. On certain timer ticks, a
merge replication is called.
I have a wrapper class that asynchronously starts the merge replication
process (using the .BeginInvoke() method). I did this so that my
service could continue to do other things while the merge replication
took place.
Through logging, I know that a separate thread is indeed handling the
replication process.
The problem is that the merge replication appears to block the calling
thread as soon as replication begins. I can see this happening because
I have logging statements inside the merge status event. I see the
calling thread continue to do work until the merge thread begins to
initialize. As soon as the merge is complete, the calling thread once
again continues.
At first I thought that maybe the entire process was blocked by the
merge replication ActiveX object, but the timer event continues to fire.
So it appears that only the calling thread is blocked.
Any ideas?
Thanks,
Jeff
are you using an MSDE database? MSDE is throttled at 8 simultaneous
workloads.
Perhaps this is the problem you are running into.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:Nu02d.286$DY.238@.chiapp18.algx.net...
> Hello,
> I have a VB.NET service that has a timer. On certain timer ticks, a
> merge replication is called.
> I have a wrapper class that asynchronously starts the merge replication
> process (using the .BeginInvoke() method). I did this so that my
> service could continue to do other things while the merge replication
> took place.
> Through logging, I know that a separate thread is indeed handling the
> replication process.
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins. I can see this happening because
> I have logging statements inside the merge status event. I see the
> calling thread continue to do work until the merge thread begins to
> initialize. As soon as the merge is complete, the calling thread once
> again continues.
> At first I thought that maybe the entire process was blocked by the
> merge replication ActiveX object, but the timer event continues to fire.
> So it appears that only the calling thread is blocked.
> Any ideas?
> Thanks,
> Jeff
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.replication:56175
Hilary Cotter wrote:
> are you using an MSDE database? MSDE is throttled at 8 simultaneous
> workloads.
No, SQL Server 2000 on both publisher/distributor and subscriber.
But besides that, even if it were being throttled - it shouldn't block
the other thread from continue to process non-SQL Server instructions.
Thanks,
Jeff
|||Can you find out what the merge replication process is doing when it blocks
the other process?
If it is applying a snapshot you can expect blocking. For the type of
singleton transactions that merge replication uses you should not
experieince this level of locking, unless perhaps you are updating columns
which have indexes on them.
You might want to run sp_lock on the client to get an idea of what sort of
locks the replication process is applying.
You might also want to see if perhaps the locking is occuring due to your
code. For instance, I do not experience any locking when using databases
which are part of a merge publication or subscription when the merge
replication agents are running and when I am running the replication process
via tsql or em. This will rule out replication and give you a better window
into what is occuring.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:7b12d.297$DY.106@.chiapp18.algx.net...
> Hilary Cotter wrote:
> No, SQL Server 2000 on both publisher/distributor and subscriber.
> But besides that, even if it were being throttled - it shouldn't block
> the other thread from continue to process non-SQL Server instructions.
> Thanks,
> Jeff
|||Hilary Cotter wrote:
> Can you find out what the merge replication process is doing when it blocks
> the other process?
Yes: It blocks the calling thread as soon as I get the "Initializing"
status until I get the "Complete" status.
> If it is applying a snapshot you can expect blocking. For the type of
> singleton transactions that merge replication uses you should not
> experieince this level of locking, unless perhaps you are updating columns
> which have indexes on them.
> You might want to run sp_lock on the client to get an idea of what sort of
> locks the replication process is applying.
It sounds like you are describing a possible lock on the database. This
is not what is happening. What I am describing is my main thread in my
application is getting blocked until the merge thread (separate from the
main thread) is complete. The main thread is not doing any database
work at all when it gets blocked by the merge thread.
> You might also want to see if perhaps the locking is occuring due to your
> code. For instance, I do not experience any locking when using databases
> which are part of a merge publication or subscription when the merge
> replication agents are running and when I am running the replication process
> via tsql or em. This will rule out replication and give you a better window
> into what is occuring.
I am sure that if I were to run the replication from tsql or em it would
not block - because of my above paragraph. It's the actual ActiveX COM
replication object that is blocking my main thread for some reason. And
like I said in my original post, I am positive that the main thread is
properly spawning a new thread for the merge.
Thanks for the ideas!
Jeff
|||If you want to send the code to me, offline I'll try to repro it.
Otherwise I suggest you open a support incident with PSS.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:K%g2d.520$DY.90@.chiapp18.algx.net...[vbcol=seagreen]
> Hilary Cotter wrote:
blocks[vbcol=seagreen]
> Yes: It blocks the calling thread as soon as I get the "Initializing"
> status until I get the "Complete" status.
columns[vbcol=seagreen]
of[vbcol=seagreen]
> It sounds like you are describing a possible lock on the database. This
> is not what is happening. What I am describing is my main thread in my
> application is getting blocked until the merge thread (separate from the
> main thread) is complete. The main thread is not doing any database
> work at all when it gets blocked by the merge thread.
your[vbcol=seagreen]
process[vbcol=seagreen]
window
> I am sure that if I were to run the replication from tsql or em it would
> not block - because of my above paragraph. It's the actual ActiveX COM
> replication object that is blocking my main thread for some reason. And
> like I said in my original post, I am positive that the main thread is
> properly spawning a new thread for the merge.
> Thanks for the ideas!
> Jeff
|||Jeff Hedlund wrote:
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins.
FYI - I have found the source of my problem. When using BeginInvoke()
to create a separate thread for the replication object, VB.NET uses a
thread from the thread pool.
The thread pool operates with the MTA apartment state. The SQL
replication ActiveX object apparently uses STA, so it was blocking the
MTA apartment while it ran. Make sure I used an STA thread to run the
SQL replication object on solved the blocking problem.
Thanks,
Jeff
sql
I have a VB.NET service that has a timer. On certain timer ticks, a
merge replication is called.
I have a wrapper class that asynchronously starts the merge replication
process (using the .BeginInvoke() method). I did this so that my
service could continue to do other things while the merge replication
took place.
Through logging, I know that a separate thread is indeed handling the
replication process.
The problem is that the merge replication appears to block the calling
thread as soon as replication begins. I can see this happening because
I have logging statements inside the merge status event. I see the
calling thread continue to do work until the merge thread begins to
initialize. As soon as the merge is complete, the calling thread once
again continues.
At first I thought that maybe the entire process was blocked by the
merge replication ActiveX object, but the timer event continues to fire.
So it appears that only the calling thread is blocked.
Any ideas?
Thanks,
Jeff
are you using an MSDE database? MSDE is throttled at 8 simultaneous
workloads.
Perhaps this is the problem you are running into.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:Nu02d.286$DY.238@.chiapp18.algx.net...
> Hello,
> I have a VB.NET service that has a timer. On certain timer ticks, a
> merge replication is called.
> I have a wrapper class that asynchronously starts the merge replication
> process (using the .BeginInvoke() method). I did this so that my
> service could continue to do other things while the merge replication
> took place.
> Through logging, I know that a separate thread is indeed handling the
> replication process.
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins. I can see this happening because
> I have logging statements inside the merge status event. I see the
> calling thread continue to do work until the merge thread begins to
> initialize. As soon as the merge is complete, the calling thread once
> again continues.
> At first I thought that maybe the entire process was blocked by the
> merge replication ActiveX object, but the timer event continues to fire.
> So it appears that only the calling thread is blocked.
> Any ideas?
> Thanks,
> Jeff
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.replication:56175
Hilary Cotter wrote:
> are you using an MSDE database? MSDE is throttled at 8 simultaneous
> workloads.
No, SQL Server 2000 on both publisher/distributor and subscriber.
But besides that, even if it were being throttled - it shouldn't block
the other thread from continue to process non-SQL Server instructions.
Thanks,
Jeff
|||Can you find out what the merge replication process is doing when it blocks
the other process?
If it is applying a snapshot you can expect blocking. For the type of
singleton transactions that merge replication uses you should not
experieince this level of locking, unless perhaps you are updating columns
which have indexes on them.
You might want to run sp_lock on the client to get an idea of what sort of
locks the replication process is applying.
You might also want to see if perhaps the locking is occuring due to your
code. For instance, I do not experience any locking when using databases
which are part of a merge publication or subscription when the merge
replication agents are running and when I am running the replication process
via tsql or em. This will rule out replication and give you a better window
into what is occuring.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:7b12d.297$DY.106@.chiapp18.algx.net...
> Hilary Cotter wrote:
> No, SQL Server 2000 on both publisher/distributor and subscriber.
> But besides that, even if it were being throttled - it shouldn't block
> the other thread from continue to process non-SQL Server instructions.
> Thanks,
> Jeff
|||Hilary Cotter wrote:
> Can you find out what the merge replication process is doing when it blocks
> the other process?
Yes: It blocks the calling thread as soon as I get the "Initializing"
status until I get the "Complete" status.
> If it is applying a snapshot you can expect blocking. For the type of
> singleton transactions that merge replication uses you should not
> experieince this level of locking, unless perhaps you are updating columns
> which have indexes on them.
> You might want to run sp_lock on the client to get an idea of what sort of
> locks the replication process is applying.
It sounds like you are describing a possible lock on the database. This
is not what is happening. What I am describing is my main thread in my
application is getting blocked until the merge thread (separate from the
main thread) is complete. The main thread is not doing any database
work at all when it gets blocked by the merge thread.
> You might also want to see if perhaps the locking is occuring due to your
> code. For instance, I do not experience any locking when using databases
> which are part of a merge publication or subscription when the merge
> replication agents are running and when I am running the replication process
> via tsql or em. This will rule out replication and give you a better window
> into what is occuring.
I am sure that if I were to run the replication from tsql or em it would
not block - because of my above paragraph. It's the actual ActiveX COM
replication object that is blocking my main thread for some reason. And
like I said in my original post, I am positive that the main thread is
properly spawning a new thread for the merge.
Thanks for the ideas!
Jeff
|||If you want to send the code to me, offline I'll try to repro it.
Otherwise I suggest you open a support incident with PSS.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:K%g2d.520$DY.90@.chiapp18.algx.net...[vbcol=seagreen]
> Hilary Cotter wrote:
blocks[vbcol=seagreen]
> Yes: It blocks the calling thread as soon as I get the "Initializing"
> status until I get the "Complete" status.
columns[vbcol=seagreen]
of[vbcol=seagreen]
> It sounds like you are describing a possible lock on the database. This
> is not what is happening. What I am describing is my main thread in my
> application is getting blocked until the merge thread (separate from the
> main thread) is complete. The main thread is not doing any database
> work at all when it gets blocked by the merge thread.
your[vbcol=seagreen]
process[vbcol=seagreen]
window
> I am sure that if I were to run the replication from tsql or em it would
> not block - because of my above paragraph. It's the actual ActiveX COM
> replication object that is blocking my main thread for some reason. And
> like I said in my original post, I am positive that the main thread is
> properly spawning a new thread for the merge.
> Thanks for the ideas!
> Jeff
|||Jeff Hedlund wrote:
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins.
FYI - I have found the source of my problem. When using BeginInvoke()
to create a separate thread for the replication object, VB.NET uses a
thread from the thread pool.
The thread pool operates with the MTA apartment state. The SQL
replication ActiveX object apparently uses STA, so it was blocking the
MTA apartment while it ran. Make sure I used an STA thread to run the
SQL replication object on solved the blocking problem.
Thanks,
Jeff
sql
Asynchronous / non-blocking trigger
Is it possible to create an asynchronous / non-blocking trigger in SQL
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
Jon
Triggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>
|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway.
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>
|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/sql/sql2005/SQL2005CreatingTSQLAsynchronousTriggers.aspx
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway.
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
Jon
Triggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>
|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway.
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>
|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/sql/sql2005/SQL2005CreatingTSQLAsynchronousTriggers.aspx
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway.
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>
Asynchronous / non-blocking trigger
Is it possible to create an asynchronous / non-blocking trigger in SQL
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
JonTriggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway. :)
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>> Is it possible to create an asynchronous / non-blocking trigger in SQL
>> Server 2005 that will allow operations to continue asynchronously while
>> the trigger can still read the in-memory "inserted" and "deleted" virtual
>> tables?
>> Thanks,
>> Jon
>|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/sql/sql2005/SQL2005CreatingTSQLAsynchronousTriggers.aspx
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway. :)
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>> Triggers always execute synchronously in the context of a transaction.
>> If you need to invoke an asynchronous process from within a trigger,
>> consider using Service Broker. Asynchronous triggers are exactly the
>> functionality that Service Broker provides. See the Books Online for
>> details.
>>
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
>> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>> Is it possible to create an asynchronous / non-blocking trigger in SQL
>> Server 2005 that will allow operations to continue asynchronously while
>> the trigger can still read the in-memory "inserted" and "deleted"
>> virtual tables?
>> Thanks,
>> Jon
>>
>
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
JonTriggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway. :)
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>> Is it possible to create an asynchronous / non-blocking trigger in SQL
>> Server 2005 that will allow operations to continue asynchronously while
>> the trigger can still read the in-memory "inserted" and "deleted" virtual
>> tables?
>> Thanks,
>> Jon
>|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/sql/sql2005/SQL2005CreatingTSQLAsynchronousTriggers.aspx
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway. :)
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>> Triggers always execute synchronously in the context of a transaction.
>> If you need to invoke an asynchronous process from within a trigger,
>> consider using Service Broker. Asynchronous triggers are exactly the
>> functionality that Service Broker provides. See the Books Online for
>> details.
>>
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
>> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>> Is it possible to create an asynchronous / non-blocking trigger in SQL
>> Server 2005 that will allow operations to continue asynchronously while
>> the trigger can still read the in-memory "inserted" and "deleted"
>> virtual tables?
>> Thanks,
>> Jon
>>
>
Asynchronous / non-blocking trigger
Is it possible to create an asynchronous / non-blocking trigger in SQL
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
JonTriggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway.
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/s...br />
ers.aspx
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway.
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>
Server 2005 that will allow operations to continue asynchronously while the
trigger can still read the in-memory "inserted" and "deleted" virtual
tables?
Thanks,
JonTriggers always execute synchronously in the context of a transaction. If
you need to invoke an asynchronous process from within a trigger, consider
using Service Broker. Asynchronous triggers are exactly the functionality
that Service Broker provides. See the Books Online for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Is it possible to create an asynchronous / non-blocking trigger in SQL
> Server 2005 that will allow operations to continue asynchronously while
> the trigger can still read the in-memory "inserted" and "deleted" virtual
> tables?
> Thanks,
> Jon
>|||So, then, no, because Service Broker doesn't retain the "inserted" and
"deleted" in-memory tables.
Thanks anyway.
Jon
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
> Triggers always execute synchronously in the context of a transaction. If
> you need to invoke an asynchronous process from within a trigger, consider
> using Service Broker. Asynchronous triggers are exactly the functionality
> that Service Broker provides. See the Books Online for details.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23jWadvEjHHA.4552@.TK2MSFTNGP05.phx.gbl...
>|||> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
Service Broker doesn't need access to inserted/deleted directly. The
trigger can pass insert data into the SB queue the from the inserted/deleted
pseudo tables. Here's an example:
http://www.dotnetfun.com/articles/s...br />
ers.aspx
Hope this helps.
Dan Guzman
SQL Server MVP
"Jon Davis" <jon@.REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e3kWlPNjHHA.4520@.TK2MSFTNGP02.phx.gbl...
> So, then, no, because Service Broker doesn't retain the "inserted" and
> "deleted" in-memory tables.
> Thanks anyway.
> Jon
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:5D57525F-1DED-4A3B-B00B-60342A369F5A@.microsoft.com...
>
Subscribe to:
Posts (Atom)