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.
| 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 dbagocreate table dmotest ( col1 varchar(8000))godeclare @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 outexec @HRESULT = sp_OASetProperty @oSQLServer, 'LoginSecure', -1exec @HRESULT = sp_OAMethod @oSQLServer, 'Connect', NULL, @@SERVERNAME/******************************************************************************* Write to the table******************************************************************************/select @replicator = 1while @replicator < = 300begin 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 endendexec @HRESULT = sp_OADestroy @oSQLServerselect max(len(col1)) + len('insert dba.dbo.dmotest values(XX)') + len('executeimmediate("")')from dmotestgodrop table dmotestgo 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> |
 |
|
|
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. |
 |
|
|
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> |
 |
|
|
|
|
|
|
|