Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 SQLDMO ExecuteImmediate

Author  Topic 

Page47
Master Smack Fu Yak Hacker

2878 Posts

Posted - 2002-04-10 : 15:56:36
SQL Server 7.0 SP3....

I am attempting to leverage the Andy Pope article and the Daniel_Buchholz script to log errors to a table outside the current transaction. Here is a code snippet . . .

use dba
go
create table dmotest (
col1 varchar(8000)
)
go

declare
@sql varchar(8000),
@method varchar(8000),
@replicator int,
@HRESULT int,
@oSQLServer int,
@oQueryResults int,
@Length int,
@ErrorMsg varchar(255),
@len int
/******************************************************************************
* Create the SQLServer object
******************************************************************************/
exec @HRESULT = sp_OACreate 'SQLDMO.SQLServer', @oSQLServer out
exec @HRESULT = sp_OASetProperty @oSQLServer, 'LoginSecure', -1
exec @HRESULT = sp_OAMethod @oSQLServer, 'Connect', NULL, @@SERVERNAME
/******************************************************************************
* Write to the table
******************************************************************************/
select
@replicator = 1

while @replicator < = 300
begin
select
@sql = 'insert dba.dbo.dmotest values(''' + replicate('X',@replicator) + ''')',
@replicator = @replicator + 1
select
@method = 'ExecuteImmediate("' + @sql + '")',
@Length = len(@sql)
exec @HRESULT = sp_OAMethod @oSQLServer, @method
-- exec @HRESULT = sp_OAMethod @oSQLServer, 'ExecuteImmediate', @Command = @sql, @ExecutionType = 0, @Length = @Length
-- exec @HRESULT = sp_OAMethod @oSQLServer, 'ExecuteWithResults', @oQueryResults OUTPUT, @Length = @Length, @Command = @SQL

if @HRESULT <> 0
begin
exec sp_oageterrorinfo @oSQLServer, @sql OUTPUT, @method output
-- print @sql
-- print @method
end
end
exec @HRESULT = sp_OADestroy @oSQLServer

select
max(len(col1)) + len('insert dba.dbo.dmotest values(XX)') + len('executeimmediate("")')
from
dmotest
go
drop table dmotest
go

 
Note: change 'dba' to <somedatabase>

Here is what I think this code reveals: the methodname and parameter arguments of the sp_OAMethod proc seems to be limited to 255 characters. I could not substantiate this claim in either BOL or a quick web search. Do you concur? If so, how would I write a 300 character 'col1' in 'dmotest'?

<O>

Edited by - Page47 on 04/10/2002 15:58:50

Page47
Master Smack Fu Yak Hacker

2878 Posts

Posted - 2002-04-11 : 09:54:37
OK...20% blatant bump, 80% legitimate follow up question(s) . . .

Assuming the silence on this thread points to me being right about the 255 limit, I am trying to think of alternative ways to accomplish the same thing. Off the top, I am thinking about creating an ADO connection. Before I actually code an attempt, does anyone know …

  • if the transaction will implicitly persist through the ADO connection and thus rollback the logging of the error when the original connect rolls back?

  • of any other way to get outside the scope of the transaction?

  • if my original deduction about the 255 limit is incorrect?

  • if the implementation of sp_OAMethod is different in SQL 2k and allows more than 255 character, in which case I will just left(error,255) for now and tell the client, “reason number 47 why you should (pay me to) upgrade to 2K”?



Thanks for any input.


<O>
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-04-11 : 10:18:58
Let me ask this: what more are you adding to the original code that Andy and Daniel posted? Or, another way of saying it, what was missing from their code, if anything?

I don't think ADO is the solution, and calling it from within an SP using sp_OA won't solve the 255 character issue (yes, this was a documented limitation in earlier versions, I'm pretty sure the behavior has NOT changed in 7.0 and higher) The only way to do that is to put the SQL statement into a table, write a COM object that queries that table and uses ADO to execute the query, then write methods that can be called using sp_OAMethod.

Sound yucky? It is, and I can't think of a way that you can get the results back to the stored procedure (if you're using a SELECT statement)

There's more than one way to skin a cat, I think another approach might be better than the ExecuteWithResults method, based on your requirements.

Go to Top of Page

Page47
Master Smack Fu Yak Hacker

2878 Posts

Posted - 2002-04-11 : 10:49:07
Rob, thanks for the reply. Actually, I had SetBased run the script in 2K and he got more than 255, so I think I will just implement the left(@error,2XX) thing . . .

The only different from the Buchholz solution is the constructor/destructor algorithms. (Note: code snippet here was created to specifically expose my issue, it is not cut & paste from my dev). I don't fully understand the Buchholz connection sharing, and actually am a bit skeptical about whether or not it will work. My implementation creates and destroys a new SQLServer object for every message to be logged.

I thought about the putting the statement into a table, but wouldn't the row be locked until the transaction either commits or rollsback, therefore it wouldn't be available to the dmo connection . . . I suppose the querying dmo connection could NOLOCK the table . . . its ugly, true . . . Like I said, I think I'll just keep the messages under 2XX . . .



<O>
Go to Top of Page
   

- Advertisement -