Re: Insert with bound columns

Did anybody succeed in inserting empty string columns using bound columns?

INSERT INTO testtab (keyCol, strCol) VALUES (1, '') or (1, NULL)
succeeds, but

INSERT INTO testtab (keyCol, strCol) VALUES (?,?) does not.

I debugged the driver and found that SQLNumParams will return 2 for the
bound column version,which is obviously correct. Unfortunately, MSDASQL
seems to expect 1 (I checked by changing it with debugger), but that
will make the ODBC driver unhappy. I changed the database access class
to replace all empty strings with a one-space string. This made MSDASQL
happy, but will not be reasonable for production.

I'm using native OLEDB, thus MSDASQL is my provider using ODBC 7.2.5
from source.
Feedback from ADO users is welcome, they're using OLEDB implicitely.

I checked MSDN and Technet for this,and traced the output of PGadmin II
which is not using bound columns so it's not helpful to me.

Any hints?

Andreas

After experimenting heavily, I found out some more.
MSDASQL doesn't like a NULL-pointer as string in the buffer to be
written. Instead, a SysAllocString(L"") is needed. This is acceptable,
if an zero length string should be inserted. If the status field of the
buffer ist not set to DBSTATUS_S_OK indicating valid data to be written,
but to DBSTATUS_S_ISNULL for a NULL to be inserted, MSDASQL will fail
with "Parameter type cannot be determined for at leas one variant
parameter". Actually, it's no variant given, but a DBTYPE_BSTR, and this
information is put correctly into the DBBINDING structure. Still, I
believe ADO users should be unable to insert a NULL string into a
VARCHAR column (if not omitted in the query).

The same (OLEDB side) code works with SQLSRV32, and MSDASQL blows as
soon as it gets to know the number of parameters, so it seems that for
SQLSRV32 MSDASQL can determine the parameter type from the SQL server
driver, but not with PostgreSQL. Does this switch on a light for
anybody, saying "ah now I know what SQLxxyy is for"? If pointed towards
some topic, I could try to implement it.

Regards,

Andreas

Andreas Pflug wrote:
>
> After experimenting heavily, I found out some more.
> MSDASQL doesn't like a NULL-pointer as string in the buffer to be
> written. Instead, a SysAllocString(L"") is needed. This is acceptable,
> if an zero length string should be inserted. If the status field of the
> buffer ist not set to DBSTATUS_S_OK indicating valid data to be written,
> but to DBSTATUS_S_ISNULL for a NULL to be inserted, MSDASQL will fail
> with "Parameter type cannot be determined for at leas one variant
> parameter". Actually, it's no variant given, but a DBTYPE_BSTR, and this
> information is put correctly into the DBBINDING structure. Still, I
> believe ADO users should be unable to insert a NULL string into a
> VARCHAR column (if not omitted in the query).

I can insert a '' or NULL using ADO.Parameter in VB.

> The same (OLEDB side) code works with SQLSRV32, and MSDASQL blows as
> soon as it gets to know the number of parameters, so it seems that for
> SQLSRV32 MSDASQL can determine the parameter type from the SQL server
> driver, but not with PostgreSQL.

The psqlodbc driver couldn't determine the parameter type
unless the upper application specifies it explicitly.

> Does this switch on a light for
> anybody, saying "ah now I know what SQLxxyy is for"? If pointed towards
> some topic, I could try to implement it.

Maybe SQLDescribeParam should be supported though I'm
not sure.

regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/