Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQLPutData does not advance param counter when SQL_NULL_DATA is passed - SQLParamData always returns SQL_NEED_DATA [ODBC145] #142

Closed
firebird-automations opened this issue May 31, 2012 · 5 comments

Comments

@firebird-automations
Copy link

Submitted by: Jojakim Stahl (jstahl)

With Parameters declared as SQL_DATA_AT_EXEC the following bug appears:

After passing SQL_NULL_DATA as length parameter to SQLPutData, the parameter pointer is not advanced and the next call to SQLParamData returns SQL_NEED_DATA for the same parameter.

This is for all parameter types - blob AND not blob.
See #⁠ODBC134 - seems to be related.

Commits: 044fa9d b3faed5

@firebird-automations
Copy link
Author

Modified by: Jojakim Stahl (jstahl)

description: With Parameters declared as SQL_DATA_AT_EXEC the following bug appears:

After passing SQL_NULL_DATA as length parameter to SQLPutData, the parameter pointer is not advanced and the next call to SQLParamData returns SQL_NEED_DATA for the same parameter.

=>

With Parameters declared as SQL_DATA_AT_EXEC the following bug appears:

After passing SQL_NULL_DATA as length parameter to SQLPutData, the parameter pointer is not advanced and the next call to SQLParamData returns SQL_NEED_DATA for the same parameter.

This is for all parameter types - blob AND not blob.
See #⁠ODBC134 - seems to be related.

@firebird-automations
Copy link
Author

Commented by: Jojakim Stahl (jstahl)

The problem was, that binding->startedTransfer flag was not set, when SQLPutData has been called with SQL_NEED_DATA.
I changed it now this way, that also for SQL_NULL_DATA the standard field setter routine is sqlPutData is used. This sets SQL_NULL_DATA for the appDescriptor and the impDescriptor.
I removed the setNull function from DescRecord class becaus it was used only in sqlPutData and seems to be dangerous. It sets a *(short*) value. When my research is right, this is only correct if the DescRecord is used for the implementationParamDescriptor. The applicationParamDescriptor should set *indicatorPtr without cast, because ODBC uses SQLLEN. Should one call setNull for the application side, the value will not be correct (high-word not modified).
I think, that this fix also solves the ticket #⁠ODBC134 but I could not test this in the short time frame I had.

--- e:\http://OdbcFb.org/DescRecord.h 2010-10-24 12:27:15.000000000 +0200
+++ ./DescRecord.h 2012-05-24 12:05:55.296222200 +0200
@@ -47,12 +47,6 @@
void putBlobSegmentData (int length, const void *bytes);
void endBlobDataTransfer();

- void setNull()
- {
- if ( indicatorPtr )
- *(short*)indicatorPtr = -1;
- }
-
int getBufferLength()
{
return ( octetLength + 1 ) * headSqlVarPtr->getSqlMultiple();
--- e:\http://OdbcFb.org/OdbcStatement.cpp 2012-03-01 11:33:55.000000000 +0100
+++ ./OdbcStatement.cpp 2012-05-24 14:14:04.793788400 +0200
@@ -3108,12 +3106,7 @@

DescRecord \*binding = applicationParamDescriptor\-\>getDescRecord \(parameterNeedData\);

- if (valueSize == SQL_NULL_DATA)
- {
- binding->setNull();
- *binding->indicatorPtr = SQL_NULL_DATA;
- }
- else if ( binding->isBlobOrArray )
+ if ( valueSize != SQL_NULL_DATA && binding->isBlobOrArray )
{
if ( !binding->startedTransfer )
binding->beginBlobDataTransfer();

@firebird-automations
Copy link
Author

Commented by: @alexpotapchenko

fixed in CVS

@firebird-automations
Copy link
Author

Modified by: @alexpotapchenko

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.0.2 [ 10465 ]

@firebird-automations
Copy link
Author

Modified by: @alexpotapchenko

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants