Oracle Consulting Oracle Training Oracle Support Development
Oracle Books
SQL Server Books
IT Books
Job Interview Books
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle


Privacy Policy


  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  

Linux Oracle commands syntax poster

ION Oracle tuning software

Oracle data dictionary reference poster

Oracle Forum

BC Oracle consulting support training

BC remote Oracle DBA   



 Copyright © 1996 -2016 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks

Hit Counter