DOCUMENT:Q216196 18-JUN-2002 [visualc] TITLE :PRB: Text Output Parameter Empty with Unicode Build PRODUCT :Microsoft C Compiler PROD/VER::5.0,6.0 OPER/SYS: KEYWORDS:kbDatabase kbMFC kbODBC kbVC500 kbVC600 kbGrpDSVCDB ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Visual C++, 32-bit Enterprise Edition, versions 5.0, 6.0 ------------------------------------------------------------------------------- SYMPTOMS ======== After calling a stored procedure that has a Varchar (Text) output parameter, no errors are thrown, but the variable that holds the output is always null. This problem only happens in Unicode builds. Standard builds work after the solution provided by the following article in the Microsoft Knowledge Base has been implemented: Q182386 PRB: Varchar Output Parameter Causes "Data Truncated" Error Note that text output parameters do not work at all unless the workaround in that article has been implemented. CAUSE ===== The cause is a bug in the Unicode section of the RFX_Text function. The Unicode section in the RFX_TextOut function is setting up a Proxy parameter, binding the real parameter to the proxy parameter, and then allocating new memory to the real parameter. The data is getting put into the bound proxy parameter correctly, but it's not getting transfered to the data member. RESOLUTION ========== The resolution is in two parts: 1. You must implement the workaround provided in the following Knowledge Base article: Q182386 PRB: Varchar Output Parameter Causes "Data Truncated" Error Without implementing this workaround, the text output parameters will not work in either Standard or Unicode builds. 2. You must move the data from the proxy parameter to the data member yourself. For example, assume we have one varchar output parameter and that we have implemented the code suggested in the Microsoft Knowledge Base article Q182386 in a function called RFX_TextOut. Assuming we have a CRecordset named RSTestTextOut that contains a CString data member called strTextOut that will hold the data, you would implement the workaround as follows: // Call our stored procedure. RSTestTextOut.Open(CRecordset::forwardOnly, _T("{CALL YourSP(?)}"), CRecordset::readOnly); //Assign the proxy parameter to our CString variable. RSTestTextOut.strTextOut = (char*)RSTestTextOut.m_pvParamProxy[0]; Our variable strTextOut now holds the value of the output parameter returned from the stored procedure. If you wanted to be more strict, you could wrap that in an #ifdef _UNICODE ... #endif section, because it's only needed in Unicode builds. Of course, if you had more than one varchar output parameter, you would need a similar line for each parameter, such as: RSTestTextOut.strTextOut2 = (char*)RSTestTextOut.m_pvParamProxy[1]; REFERENCES ========== For additional information about Text parameters in Unicode builds, please see the following article in the Microsoft Knowledge Base: Q182386 PRB: Varchar Output Parameter Causes "Data Truncated" Error Additional query words: ====================================================================== Keywords : kbDatabase kbMFC kbODBC kbVC500 kbVC600 kbGrpDSVCDB Technology : kbVCsearch kbAudDeveloper kbVC500 kbVC600 kbVC32bitSearch kbVC500Search Version : :5.0,6.0 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.