On Wed, 2002-07-03 at 14:14, Tim Bunce wrote: > On Wed, Jul 03, 2002 at 11:34:17AM -0700, David L. Good wrote: > > Nope, DBD::ODBC doesn't have that functionality. I submitted a patch a > > couple of years ago to address the issue, but it kinda got lost in the > > shuffle and I moved on to other projects without following up on it. I > > hope to re-integrate the patch into the latest DBD::ODBC soon, but I'm > > still trying to get access to an appropriate Windows box... > > Please discuss on dbi-dev first as I'd like to consider defining a > standard API for that kind of functionality.
OK - just to explain what this is all about: Sybase and MS-SQL have a number of commands that generate output that is not a normal result set. These include DBCC (database consistency checker), SHOWPLAN (query plan display), STATISTICS (number of IO/millisecs for an operation). In addition, Transact-SQL supports a PRINT statement that results in the same behavior, but with no "error" number. At the protocol level these are returned as messages, and (at least with Sybase) you define a callback handler in C to catch these messages and do something with them. For example, running a DBCC checkdb() command results in something like this: 2536 2 10 Checking BugTrack 2536 3 10 Checking sysobjects 2579 1 10 The total number of data pages in this table is 3. 7929 1 10 Table has 39 data rows. 2536 3 10 Checking sysindexes 2579 1 10 The total number of data pages in this table is 6. 7929 1 10 Table has 55 data rows. etc. In this case the third column is the "severity" of the "error" - 10 means it's an informational message. If DBCC encounters a real error it will return a message with a higher severity: 11203 1 16 The command 'DBCC' is not legal when the remote object (xptool...TimeZone) has been defined as an RPC. I've used this functionality to write small scripts that compute the number of logical IOs for a SQL batch or a stored proc. This is really useful when you are trying to find the most efficient syntax for a query or a set of queries. DBD::Sybase handles this by letting the user define an error handler that is called before DBI realizes that there has been an error. The handler can then return 0 to suppress the error, or non-0 to let DBI handle the error (eg with RaiseError/PrintError). As an aside - at the C API level Sybase uses callbacks for lots of other things - for example for asynchronous requests completion notification. Michael -- Michael Peppler / [EMAIL PROTECTED] / http://www.mbay.net/~mpeppler [EMAIL PROTECTED] / ZetaTools, Inc / http://www.zetatools.com ZetaTools: Call perl functions as Sybase stored procedures!
signature.asc
Description: This is a digitally signed message part
