| |
 |
|
SQL Server Tips by Burleson |
Provide automatic conversion of parameter data
types
The CExtendedStoredProcedure also maintains a corresponding array
for each definition of a parameter. Each element in this array
corresponds to the information obtained for each parameter at
runtime. Each element in this array contains 7 variables namely: ‘m_bType’,
‘m_cbMaxLen’, ‘m_cbActualLen’, ‘m_fNull’, ‘m_pData’,
‘m_bActualOutputParameter’ and ‘m_Data’. These variables get filled
in when the XP is run by calling the srv_paraminfo and
srv_paramstatus ODS functions.
‘m_bType’ corresponds to the actual runtime data type for the
parameter. This corresponds to one of the standard SQL Server SRV…
constants.
‘m_cbMaxLen’ is the maximum size in bytes which this parameter can
be.
‘m_cbActualLen’ is the actual size in bytes which this parameter is.
‘m_fNull’ is TRUE if the parameter is a database null field,
otherwise FALSE.
‘m_pData’ is a BYTE pointer to the actual data for the parameter.
‘m_bActualOutputParmeter’ is TRUE if the parameter is an OUTPUT
parameter, otherwise FALSE, which implies that the parameter is an
INPUT parameter.
Before we discuss the ‘m_Data’ variable, we first need to talk about
the considerable boilerplate code which is often required to convert
incoming parameters to a suitable data type before XP code can
operate on them. For example, in the CSaveFileStoredProcedure
example we have been using, we need the first parameter, which is
the file name to be in a format so that we can easily call the
Windows SDK function ‘CreateFile’. Most developers will know that
functions in the Win32 SDK that take a string as a parameter have
two versions, one which takes an ASCII string and one which takes a
UNICODE string. On the versions of Windows based on the NT Kernel
(NT 4, Windows 2000, XP and Windows 2003), the ASCII version is a
simple wrapper around calling the actual Unicode implementation. The
upshot of this is that we would like a LPCTSTR string to easily
allow us to call the CreateFile function. If we were going to use
this string in a COM function, we would like a UNICODE string and if
we were interfacing with the standard ‘C’ runtime library we could
like an ASCII string. The third parameter for the
CSaveFileStoredProcedure provides another example of this. We would
like it to accept any integer type but would like to easily use the
largest of these integer types in the XP code without recourse to
calling srv_convert or doing C style casts.
The above book excerpt is from:
Super SQL
Server Systems
Turbocharge Database Performance with C++ External Procedures
ISBN:
0-9761573-2-2
Joseph Gama, P. J. Naughter
http://www.rampant-books.com/book_2005_2_sql_server_external_procedures.htm |
