G
Guest
I thought someone over here might be able to help me with this problem from a
different angle. I posted on SQLServer.programming too, I apologize if this
is considered bad form. I would be using ADO record sets, and am familiar
with what's involved in calling a SP using that technology.
Back on 9/21/2004, Dan Ganiere asked about executing T-SQL asynchronously.
T-SQL itself doesn't support that, but Gregory A. Larsen had a work around.
Unfortunately, he used sp_OACreate, sp_OAGetErrorInfo, sp_OAMethod,
sp_OADestroy, which require my server to be reconfigured, and it's looking
like that will be a no go.
I would like to bring this issue up again. I want to fire a SP from Excel,
but I don't want to tie up Excel while executing a potentially long running
PROC bulk inserting and processing a file. (Excel made the file, that's how
it knows to tell SQL Server to run the proc)
Is there a way I can call something that returns control back to Excel right
away, that doesn't require me to reconfigure the server.
Bob
different angle. I posted on SQLServer.programming too, I apologize if this
is considered bad form. I would be using ADO record sets, and am familiar
with what's involved in calling a SP using that technology.
Back on 9/21/2004, Dan Ganiere asked about executing T-SQL asynchronously.
T-SQL itself doesn't support that, but Gregory A. Larsen had a work around.
Unfortunately, he used sp_OACreate, sp_OAGetErrorInfo, sp_OAMethod,
sp_OADestroy, which require my server to be reconfigured, and it's looking
like that will be a no go.
I would like to bring this issue up again. I want to fire a SP from Excel,
but I don't want to tie up Excel while executing a potentially long running
PROC bulk inserting and processing a file. (Excel made the file, that's how
it knows to tell SQL Server to run the proc)
Is there a way I can call something that returns control back to Excel right
away, that doesn't require me to reconfigure the server.
Bob