Open brandonp42 opened 7 months ago
TBH I don't even know why we need to call SQLProcedures/SQLProcedureColumns. The user provides the schema, procedure name, and parameters. It should be simple enough to generate a {call <procedure>(?,?,?,?)}
based on the schema and procedure name along with the number of question marks based on the number of parameters passed in.
Then once you SQLPrepare
the generated call escape sequence, you can use SQLDescribeParam
, etc to determine what the parameters are.
Like all that could be done in https://github.com/markdirish/node-odbc/blob/d00c3ee6839ff67ca4415d53b0b9541e1fbec14a/lib/Connection.js#L161 and wouldn't need any C++ code for it at all.
Well, it wouldn't but there's no method to bind output or inout parameters currently.
Like all that could be done in
and wouldn't need any C++ code for it at all. Well, it wouldn't but there's no method to bind output or inout parameters currently.
I haven't been communicating well on this project, but I do have a branch I am working on currently to get INOUT and OUT parameters working with the general Query flow (+ a call to SQLGetDescField
to get the INOUT type) so that we can do exactly what you suggest with the SQLPrepare
workflow. That way we can cut out the SQLProcedures
and SQLProcedureColumns
business.
Right now I am going through the cwb trace and trying to determine why my call to SQLGetDescField
is failing in this package when it succeeds in a minimal .c file that I compile by hand.
How soon will the updated query flow code be ready? Will it support capturing the return value from a stored procedure?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
fixes #372
So far I have only tested this on IBMi with a test fix ODBC driver from IBM.