Re: pgsqODBC binding parameters II (fwd)

Ludek Finstrle wrote:

[snip]

> 
> > Reading SQLPutData's spec together with SQLBindParameter's
> 
> Where can I find these spec?
> 

The following is an extract of SQLPutData's spec.

SQLRETURN SQLPutData(
     SQLHSTMT     StatementHandle,
     SQLPOINTER     DataPtr,
     SQLINTEGER     StrLen_or_Ind);
Arguments 

.
.
DataPtr 
  [Input]
  Pointer to a buffer containing the actual data for the parameter
  or column. The data must be in the C data type specified in the
  ValueType argument of SQLBindParameter (for parameter data) or the
  TargetType argument of SQLBindCol (for column data). 
StrLen_or_Ind 
  [Input]
  Length of *DataPtr. Specifies the amount of data sent in a call to    
  SQLPutData. The amount of data can vary with each call for a given    
  parameter or column. StrLen_or_Ind is ignored unless it meets one
  of the following conditions: 
  ) strLen_or_Ind is SQL_NTS, SQL_NULL_DATA, or SQL_DEFAULT_PARAM. 
  ) The C data type specified in SQLBindParameter or SQLBindCol
    is SQL_C_CHAR or SQL_C_BINARY. 
  ) The C data type is SQL_C_DEFAULT, and the default C data type for
    the specified SQL data type is SQL_C_CHAR or SQL_C_BINARY. 
  For all other types of C data, if StrLen_or_Ind is not SQL_NULL_DATA
  or SQL_DEFAULT_PARAM, the driver assumes that the size of the
  *DataPtr buffer is the size of the C data type specified with
  ValueType or TargetType and sends the entire data value. ... 

It seems to me that the last part of this extract corresponds
to your case.

> > one, I couldn't find any description that the 9-th parameter of
> > SQLBindParameter could specifiy the SQLPutData's data length.
> > According to SQLPutData's spec, the length seems to be
> > determined by the type of the parameter though I'm not sure.
> 
> I copy it from string version and delete +1 (length).  I think this
> is good way. Length can't be determined by the type.  CHAR or VARCHAR
> could have different lengths.

I'm referring to the cases other than CHAR/VARCHAR ones.
CHAR/VARCHAR cases must accept the 4th paramerter of
SQLPutData like your patch does.

Hiroki Kataoka provided a patch to solve your problem
together with some other ones. See my next posting.

regards,
Hiroshi Inoue