Re^2: DBI/ODBC error: "Optional feature not implemented (SQL-HYC00)"

[HelenCr]

Dear mje

Nice meeting you, and thank you for your thoughtful post.

I went ahead and got rid of the SQL type binding, and the program ran along happily.

But this is a workaround.

"...it can usually (although not always) describe them via SQLDescribeParam and it can convert them internally..."
The reason I added the SQL typing in the first place, was because I've encountered a situation where Perl didn't know that the incoming insert was a string, and thought it was an integer (that happens when you have a subroutine in one package, doing the execute_array, and the original call is outside the package).

"...in Perl all your data is string data anyway..."
I have several cases where the table index is an integer, not a string.

Referring to your suggestion:
set DBI_TRACE=DBD=x.log
where is that command entered? at the command line DOS window? and is x.log the filename?
I'll use it next time I hit a DBI/DBD::ODBC error.

Many TIA

Helen

[mje]

I'm not saying there are no situations where a type should be specified (in fact the faq I pointed to you at illustrates one).

You look to be using two different ODBC drivers (or at least two different versions). You could find one needs the overriding and the other does not. We cannot tell that without seeing the log.

The biggest problem with SQLDescribeParam (what DBD::ODBC uses to find the parmeter types out) is that the ODBC driver has to rearrange your SQL to find the column types and sometimes it can get this wrong i.e., some sql statements can work, and some can fail. DBD::ODBC tries very hard to get around this.

My point about all your data is a string, is that as far as DBD::ODBC is concerned it is a string - it is bound with a SQL_VARCHAR or SQL_WVARCHAR. The binding type you pass to bind_param overrides the type passed to SQLBindParameter telling the driver what to convert it to - there is a subtle difference.

If you can reproduce the issue you found with I've encountered a situation where Perl didn't know that the incoming insert was a string, and thought it was an integer I would love to see it as that doesn't sound at all right to me.

I assumed you were running on windows so the set command would be issued in a command shell (followed by running your perl program) and would tell DBD::ODBC to send all trace output to x.log. If you are on Unix it would be "export DBI_TRACE=DBD=x.log". I'd very much like to see your trace output for the original problem you outlined (with the parameter types as you first had them).

[HelenCr]

mje: I have to work on a different project branch right now, but I'll return to this within about a week or so, try to reproduce the error, (+ trace), and report.

Many thanks

Helen