Hello Jenny, you cannot avoid the copying around of c to ODBC as the internal representation sometimes changes (internal number format used in the protocol to the kernel, values need to packetized anyway).
The coincidence that you can use the SQL type for the C type is simply that the constants mostly match (look into SQLEXT.H). I think it is not wise to "trust" the database to find a reasonable type (as you might get back esoteric types like SQL_C_DECIMAL sometimes..) and hope you have enough metainformation to choose the correct type. (you might take SQL_C_DEFAULT but you still have to know somewhere which mapping will follow. see the caveats in the Microsoft ODBC documentation around "Default C Data Types") Browse around http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcdefault_c_data_types.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcconverting_data_from_sql_to_c_data_types.asp hope that helps Wolf ps: navigation within msdn doesnt even work reasonably with my IE ;( Jenny Zhang <[EMAIL PROTECTED]> schrieb am 28.03.02: > To avoid coping data from c data structure to ODBC data structure, > I want to bind parameter to C type. Basically, let 'ParameterValuePtr' point to a C >type. I did some test, and it seems working. I want to check if there is any factor >that I should be aware of if want to take that path. Any comments are welcome. > ______________________________________________________________________________ Geben Sie Ihren Lottotipp gerne auf den letzten Dr�cker ab?Beim WEB.DE Lottoservice gibt's keine Warteschlangen. http://tippen2.web.de/?x=9 _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
