Обсуждение: pgsqODBC binding parameters II (fwd)
Hello,
please, could some expert answer?
Luf
----- Forwarded message from Ludek Finstrle <xfinstrl@informatics.muni.cz> -----
> From: Ludek Finstrle <xfinstrl@informatics.muni.cz>
> Subject: [ODBC] pgsqODBC binding parameters II
> Date: Fri, 9 Feb 2001 14:10:58 +0100
> To: pgsql-odbc@postgresql.org
> Sender: pgsql-odbc-owner@postgresql.org
>
> Hello,
>
> now I try my problem with psqlODBC version 7.01.02 and I still have problem.
> I resolve it (patch included) but I don't now if it is good problem solution.
> So this is problem log:
>
> mylog_XXX.log:
> ------
> SQLAllocStmt: entering...
> **** SQLAllocStmt: hdbc = 21789560, stmt = 22872128
> CC_add_statement: self=21789560, stmt=22872128
> SQLPrepare: entering...
> **** SQLPrepare: STMT_ALLOCATED, copy
> SC_pre_execute: status = 1
> preprocess: status = READY
> SQLExecute: entering...
> SQLExecute: clear errors...
> SQLExecute: copying statement params: trans_status=1, len=111, stmt='insert into category (mslink, cname, indextype,
indexname,indexlevel) values (?, 'alfik', 'tiled', 'alfik', 1)'
> stmt_with_params = 'insert into category (mslink, cname, indextype, indexname, indexlevel) values ('
> it's NOT a select statement: stmt=22872128
> send_query(): conn=21789560, query='insert into category (mslink, cname, indextype, indexname, indexlevel) values ('
> send_query: done sending query
> send_query: got id = 'Z'
> read 44, global_socket_buffersize=4096
> send_query: got id = 'E'
> send_query: 'E' - ERROR: parser: parse error at or near ""
> in QR_Constructor
> exit QR_Constructor
> STATEMENT ERROR: func=SC_execute, desc='', errnum=-1, errmsg='Error while executing the query (non-fatal)'
> CONN ERROR: func=SC_execute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""'
> preprocess: after status = FINISHED, so set PREMATURE
> SQLNumResultCols: result = 21834240, status = 2, numcols = 0
> SQLBindParameter: entering...
> SQLBindParamater: ipar=0, paramType=1, fCType=-16, fSqlType=4, cbColDef=10, ibScale=0, rgbValue=1, *pcbValue = -2,
data_at_exec= 0
> SQLExecute: entering...
> STATEMENT ERROR: func=SQLExecute, desc='', errnum=-1, errmsg='Error while executing the query (non-fatal)'
> CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""'
> SQLExecute: premature statement so return SQL_ERROR
> **** SQLError: henv=0, hdbc=0, hstmt=22872128
> SC_get_error: status = -1, msg = #Error while executing the query (non-fatal);
> ERROR: parser: parse error at or near ""#
> szSqlState = '00000', szError='Error while executing the query (non-fatal);
> ERROR: parser: parse error at or near ""'
> **** SQLError: henv=0, hdbc=0, hstmt=22872128
> returning NO_DATA_FOUND
> SQLFreeStmt: entering...hstmt=22872128, fOption=1
> QResult: in DESTRUCTOR
> QResult: free memory in, fcount=0
> QResult: free memory out
> QResult: exit DESTRUCTOR
> SC_Destructor: self=22872128, self->result=0, self->hdbc=21789560
> SC_free_params: ENTER, self=22872128
> SC_free_params: EXIT
> SC_Destructor: EXIT
>
> psqlodbc_XXX.log:
> -----
>
> conn=21789560, query='insert into category (mslink, cname, indextype, indexname, indexlevel) values ('
> ERROR from backend during send_query: 'ERROR: parser: parse error at or near ""'
> STATEMENT ERROR: func=SC_execute, desc='', errnum=-1, errmsg='Error while executing the query (non-fatal)'
> ------------------------------------------------------------
> hdbc=21789560, stmt=22872128, result=21834240
> manual_result=0, prepare=1, internal=0
> bindings=0, bindings_allocated=0
> parameters=0, parameters_allocated=0
> statement_type=1, statement='insert into category (mslink, cname, indextype, indexname, indexlevel)
values(?, 'alfik', 'tiled', 'alfik', 1)'
> stmt_with_params='insert into category (mslink, cname, indextype, indexname, indexlevel) values ('
> data_at_exec=-1, current_exec_param=-1, put_data=0
> currTuple=-1, current_col=-1, lobj_fd=-1
> maxRows=0, rowset_size=1, keyset_size=0, cursor_type=0, scroll_concurrency=1
> cursor_name='SQL_CUR015D0040'
> ----------------QResult Info -------------------------------
> fields=21830064, manual_tuples=0, backend_tuples=0, tupleField=0, conn=0
> fetch_count=0, fcount=0, num_fields=0, cursor='(NULL)'
> message='(NULL)', command='(NULL)', notice='(NULL)'
> status=6, inTuples=0
> CONN ERROR: func=SC_execute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""'
> ------------------------------------------------------------
> henv=21823504, conn=21789560, status=1, num_stmts=16
> sock=21830208, stmts=21830128, lobj_type=-999
> ---------------- Socket Info -------------------------------
> socket=164, reverse=0, errornumber=0, errormsg='(NULL)'
> buffer_in=21796032, buffer_out=21800136
> buffer_filled_in=44, buffer_filled_out=0, buffer_read_in=44
> STATEMENT ERROR: func=SQLExecute, desc='', errnum=-1, errmsg='Error while executing the query (non-fatal)'
> ------------------------------------------------------------
> hdbc=21789560, stmt=22872128, result=21834240
> manual_result=0, prepare=1, internal=0
> bindings=0, bindings_allocated=0
> parameters=21834176, parameters_allocated=1
> statement_type=1, statement='insert into category (mslink, cname, indextype, indexname, indexlevel)
values(?, 'alfik', 'tiled', 'alfik', 1)'
> stmt_with_params='insert into category (mslink, cname, indextype, indexname, indexlevel) values ('
> data_at_exec=-1, current_exec_param=-1, put_data=0
> currTuple=-1, current_col=-1, lobj_fd=-1
> maxRows=0, rowset_size=1, keyset_size=0, cursor_type=0, scroll_concurrency=1
> cursor_name='SQL_CUR015D0040'
> ----------------QResult Info -------------------------------
> fields=21830064, manual_tuples=0, backend_tuples=0, tupleField=0, conn=0
> fetch_count=0, fcount=0, num_fields=0, cursor='(NULL)'
> message='(NULL)', command='(NULL)', notice='(NULL)'
> status=6, inTuples=0
> CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""'
> ------------------------------------------------------------
> henv=21823504, conn=21789560, status=1, num_stmts=16
> sock=21830208, stmts=21830128, lobj_type=-999
> ---------------- Socket Info -------------------------------
> socket=164, reverse=0, errornumber=0, errormsg='(NULL)'
> buffer_in=21796032, buffer_out=21800136
> buffer_filled_in=44, buffer_filled_out=0, buffer_read_in=44
>
>
> End of logs.
>
>
> So I try make a patch. Could someone check or try it?
> Here is a patch created with 'diff -iwaru postsrc-orig postsrc-patched':
>
> -------------------------- diff begin --------------------------------
> diff -iwaru postsrc-orig/bind.c postsrc-patched/bind.c
> --- postsrc-orig/bind.c Fri Feb 9 14:01:02 2001
> +++ postsrc-patched/bind.c Wed Feb 7 16:18:52 2001
> @@ -129,11 +129,10 @@
> stmt->parameters[ipar].EXEC_buffer = NULL;
> }
>
> - /* Data at exec macro only valid for C char/binary data */
> - if ((fSqlType == SQL_LONGVARBINARY || fSqlType == SQL_LONGVARCHAR) && pcbValue && *pcbValue <=
SQL_LEN_DATA_AT_EXEC_OFFSET)
> + /* Luf Begin */
> stmt->parameters[ipar].data_at_exec = TRUE;
> - else
> - stmt->parameters[ipar].data_at_exec = FALSE;
> + /* Luf End */
> +
>
> mylog("SQLBindParamater: ipar=%d, paramType=%d, fCType=%d, fSqlType=%d, cbColDef=%d, ibScale=%d, rgbValue=%d,
*pcbValue= %d, data_at_exec = %d\n", ipar, fParamType, fCType, fSqlType, cbColDef, ibScale, rgbValue, pcbValue ?
*pcbValue:-777, stmt->parameters[ipar].data_at_exec);
>
> diff -iwaru postsrc-orig/execute.c postsrc-patched/execute.c
> --- postsrc-orig/execute.c Fri Feb 9 14:01:03 2001
> +++ postsrc-patched/execute.c Wed Feb 7 16:35:06 2001
> @@ -190,6 +190,9 @@
> StatementClass *stmt = (StatementClass *) hstmt;
> ConnectionClass *conn;
> int i, retval;
> +/* Luf Begin */
> +short ipar;
> +/* Luf End */
>
>
> mylog("%s: entering...\n", func);
> @@ -277,6 +280,18 @@
> if (stmt->data_at_exec > 0)
> return SQL_NEED_DATA;
>
> + /* Luf - Begin */
> + /* Are there any data at execution parameters? (yes = return need data) */
> + SQLNumParams(stmt,&ipar);
> + if (!((stmt->data_at_exec == -1) && (ipar == 0)) && (ipar > stmt->data_at_exec)) {
> + stmt->data_at_exec = ipar;
> + stmt->current_exec_param = 0;
> + stmt->put_data = TRUE;
> + mylog("SQL need data,\n");
> + return SQL_NEED_DATA;
> + }
> + /* Luf - End */
>
> mylog("%s: copying statement params: trans_status=%d, len=%d, stmt='%s'\n", func, conn->transact_status,
strlen(stmt->statement),stmt->statement);
>
> @@ -689,28 +704,43 @@
> mylog("lo_write: cbValue=%d, wrote %d bytes\n", cbValue, retval);
>
> }
> - else { /* for handling text fields and small binaries */
> + /* Luf Begin */
> + else { /* for handling fields */
> + /* Luf End */
>
> if (cbValue == SQL_NTS) {
> current_param->EXEC_buffer = strdup(rgbValue);
> if ( ! current_param->EXEC_buffer) {
> stmt->errornumber = STMT_NO_MEMORY_ERROR;
> - stmt->errormsg = "Out of memory in SQLPutData (2)";
> + stmt->errormsg = "Out of memory in SQLPutData (2-1)";
> SC_log_error(func, "", stmt);
> return SQL_ERROR;
> }
> - }
> - else {
> + /* Luf Begin */
> + } else if (cbValue == SQL_NTSL) {
> + /* Luf End */
> current_param->EXEC_buffer = malloc(cbValue + 1);
> if ( ! current_param->EXEC_buffer) {
> stmt->errornumber = STMT_NO_MEMORY_ERROR;
> - stmt->errormsg = "Out of memory in SQLPutData (2)";
> + stmt->errormsg = "Out of memory in SQLPutData (2-2)";
> SC_log_error(func, "", stmt);
> return SQL_ERROR;
> }
> memcpy(current_param->EXEC_buffer, rgbValue, cbValue);
> current_param->EXEC_buffer[cbValue] = '\0';
> + /* Luf Begin */
> + } else {
> + mylog("DataPut cbValue = %d, rgbValue = %ld\n",current_param->buflen,*((SDWORD *) rgbValue));
> + current_param->EXEC_buffer = malloc(current_param->buflen);
> + if ( ! current_param->EXEC_buffer) {
> + stmt->errornumber = STMT_NO_MEMORY_ERROR;
> + stmt->errormsg = "Out of memory in SQLPutData (2-3)";
> + SC_log_error(func, "", stmt);
> + return SQL_ERROR;
> + }
> + memcpy(current_param->EXEC_buffer, rgbValue, current_param->buflen);
> }
> + /* Luf End */
> }
> }
>
> diff -iwaru postsrc-orig/parse.c postsrc-patched/parse.c
> --- postsrc-orig/parse.c Fri Feb 9 14:01:04 2001
> +++ postsrc-patched/parse.c Wed Feb 7 16:29:20 2001
> @@ -691,6 +691,9 @@
> stmt->parse_status = STMT_PARSE_FATAL;
> return FALSE;
> }
> + /* Luf Bug fix */
> + stmt->fi = fi;
> + /* Luf End */
> }
>
> /*------------------------------------------------------------- */
> diff -iwaru postsrc-orig/results.c postsrc-patched/results.c
> --- postsrc-orig/results.c Fri Feb 9 14:01:05 2001
> +++ postsrc-patched/results.c Wed Feb 7 16:33:36 2001
> @@ -136,19 +136,21 @@
>
> if ( ! parse_ok) {
>
> + /* Luf - Begin
> SC_pre_execute(stmt);
> + /* Luf - End */
> result = SC_get_Result(stmt);
>
> mylog("SQLNumResultCols: result = %u, status = %d, numcols = %d\n", result, stmt->status, result != NULL ?
QR_NumResultCols(result): -1);
> if (( ! result) || ((stmt->status != STMT_FINISHED) && (stmt->status != STMT_PREMATURE)) ) {
> /* no query has been executed on this statement */
> - stmt->errornumber = STMT_SEQUENCE_ERROR;
> - stmt->errormsg = "No query has been executed with that handle";
> - SC_log_error(func, "", stmt);
> - return SQL_ERROR;
> - }
> -
> + /* Luf - Begin */
> + stmt->nfld = 0;
> + *pccol = stmt->nfld;
> + } else {
> *pccol = QR_NumResultCols(result);
> + }
> + /* Luf End */
> }
>
> return SQL_SUCCESS;
> --------------------------- diff end ---------------------------------
>
> Luf
----- End forwarded message -----
Ludek Finstrle wrote: > > Hello, > > please, could some expert answer? > Though I'm not an expert, I have a question. [snip] > > CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""' > > SQLExecute: premature statement so return SQL_ERROR PREMATURE state of the statement seems to be the cause of the error. Is your change about data_at_exec to prevent the PREMATURE state just after the return from SQLNumResultCols ? Or does it have another purpose ? regards, Hiroshi Inoue
> > please, could some expert answer? > > Though I'm not an expert, I have a question. > > [snip] > > > > CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""' > > > SQLExecute: premature statement so return SQL_ERROR > > PREMATURE state of the statement seems to be the cause of > the error. Is your change about data_at_exec to prevent the > PREMATURE state just after the return from SQLNumResultCols ? > Or does it have another purpose ? Sorry, I don't understand question very well. I make it in december. So I don't remember details. The problem was that '?' didn't be detect as parametr at exec. So I added detection of parameters at exec to SQLExecute. And if I detect it I return SQL_NEED_DATA. Do you want logs with successfull execute? Luf
Ludek Finstrle wrote: > > > > please, could some expert answer? > > > > Though I'm not an expert, I have a question. > > > > [snip] > > > > > > CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""' > > > > SQLExecute: premature statement so return SQL_ERROR > > > > PREMATURE state of the statement seems to be the cause of > > the error. Is your change about data_at_exec to prevent the > > PREMATURE state just after the return from SQLNumResultCols ? > > Or does it have another purpose ? > > Sorry, I don't understand question very well. > I make it in december. So I don't remember details. > > The problem was that '?' didn't be detect as parametr at exec. > So I added detection of parameters at exec to SQLExecute. And if I detect > it I return SQL_NEED_DATA. > '?' doesn't necessarily mean a data_at_execution parameter. Doesn't your patch change all parameters to data_at_exec ones ? If so it doesn't seem good. regards, Hiroshi Inoue
> > > > > CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""' > > > > > SQLExecute: premature statement so return SQL_ERROR > > > > > > PREMATURE state of the statement seems to be the cause of > > > the error. Is your change about data_at_exec to prevent the > > > PREMATURE state just after the return from SQLNumResultCols ? > > > Or does it have another purpose ? > > > > Sorry, I don't understand question very well. > > I make it in december. So I don't remember details. > > > > The problem was that '?' didn't be detect as parametr at exec. > > So I added detection of parameters at exec to SQLExecute. And if I detect > > it I return SQL_NEED_DATA. > > > > '?' doesn't necessarily mean a data_at_execution parameter. I use SQLNumParams for this detection. So I mean that it's safe. > Doesn't your patch change all parameters to data_at_exec ones ? > If so it doesn't seem good. Yes, it does. Any idea how recognize data_at_exec parameters? Luf
Ludek Finstrle wrote:
>
> > > > > > CONN ERROR: func=SQLExecute, desc='', errnum=110, errmsg='ERROR: parser: parse error at or near ""'
> > > > > > SQLExecute: premature statement so return SQL_ERROR
> > > >
> > > > PREMATURE state of the statement seems to be the cause of
> > > > the error. Is your change about data_at_exec to prevent the
> > > > PREMATURE state just after the return from SQLNumResultCols ?
> > > > Or does it have another purpose ?
> > >
> > > Sorry, I don't understand question very well.
> > > I make it in december. So I don't remember details.
> > >
> > > The problem was that '?' didn't be detect as parametr at exec.
> > > So I added detection of parameters at exec to SQLExecute. And if I detect
> > > it I return SQL_NEED_DATA.
> > >
> >
> > '?' doesn't necessarily mean a data_at_execution parameter.
>
> I use SQLNumParams for this detection. So I mean that it's safe.
>
> > Doesn't your patch change all parameters to data_at_exec ones ?
> > If so it doesn't seem good.
>
> Yes, it does. Any idea how recognize data_at_exec parameters?
>
I see the following in your log.
> SQLBindParameter: entering...
> SQLBindParamater: ipar=0, paramType=1, fCType=-16, fSqlType=4,
cbColDef=10, ibScale=0, rgbValue=1, *pcbValue = -2, data_at_exec = 0
'*pcbValue = -2' seems to mean SQL_DATA_AT_EXEC.
BTW I see the following in your patch.
Isn't SQL_NTSL -3L ?
If so what does 'malloc(cbValue + 1)' mean ?
> - }
> - else {
> + /* Luf Begin */
> + } else if (cbValue == SQL_NTSL) {
> + /* Luf End */
> current_param->EXEC_buffer =
malloc(cbValue + 1);
regards,
Hiroshi Inoue
> > > Doesn't your patch change all parameters to data_at_exec ones ?
> > > If so it doesn't seem good.
> >
> > Yes, it does. Any idea how recognize data_at_exec parameters?
>
> I see the following in your log.
>
> > SQLBindParameter: entering...
> > SQLBindParamater: ipar=0, paramType=1, fCType=-16, fSqlType=4,
> cbColDef=10, ibScale=0, rgbValue=1, *pcbValue = -2, data_at_exec = 0
>
> '*pcbValue = -2' seems to mean SQL_DATA_AT_EXEC.
Yes. It's true;
> BTW I see the following in your patch.
> Isn't SQL_NTSL -3L ?
> If so what does 'malloc(cbValue + 1)' mean ?
I want to detect char but this is wrong way.
I apllied your tips and patch now looks:
-------- Start patch (diff -iwaru postsrc-orig postsrc-patched) -------
diff -iwaru postsrc-orig/bind.c postsrc-patched/bind.c
--- postsrc-orig/bind.c Fri Mar 23 10:37:45 2001
+++ postsrc-patched/bind.c Fri Mar 23 10:56:09 2001
@@ -143,8 +143,8 @@
stmt->parameters[ipar].EXEC_buffer = NULL;
}
- /* Data at exec macro only valid for C char/binary data */
- if ((fSqlType == SQL_LONGVARBINARY || fSqlType == SQL_LONGVARCHAR) && pcbValue && *pcbValue <=
SQL_LEN_DATA_AT_EXEC_OFFSET)
+ /* Data at exec macro */
+ if (((fSqlType == SQL_LONGVARBINARY || fSqlType == SQL_LONGVARCHAR) && pcbValue && *pcbValue <=
SQL_LEN_DATA_AT_EXEC_OFFSET)|| *pcbValue == SQL_DATA_AT_EXEC)
stmt->parameters[ipar].data_at_exec = TRUE;
else
stmt->parameters[ipar].data_at_exec = FALSE;
diff -iwaru postsrc-orig/execute.c postsrc-patched/execute.c
--- postsrc-orig/execute.c Fri Mar 23 10:37:47 2001
+++ postsrc-patched/execute.c Fri Mar 23 10:55:56 2001
@@ -778,33 +778,46 @@
}
else
- { /* for handling text fields and small
- * binaries */
+ { /* for handling fields */
if (cbValue == SQL_NTS)
{
+ mylog("DataPut NTS cbValue = %d, rgbValue = %l d\n",current_param->buflen,*((SDWORD *) rgbValue));
current_param->EXEC_buffer = strdup(rgbValue);
if (!current_param->EXEC_buffer)
{
stmt->errornumber = STMT_NO_MEMORY_ERROR;
- stmt->errormsg = "Out of memory in SQLPutData (2)";
+ stmt->errormsg = "Out of memory in SQLPutData (2-1)";
SC_log_error(func, "", stmt);
return SQL_ERROR;
}
}
- else
+ else if (current_param->SQLType == SQL_CHAR || current_param->SQLType == SQL_VARCHAR) {
{
+ mylog("DataPut CHAR cbValue = %d, rgbValue = %l d\n",current_param->buflen,*((SDWORD *) rgbValue));
current_param->EXEC_buffer = malloc(cbValue + 1);
if (!current_param->EXEC_buffer)
{
stmt->errornumber = STMT_NO_MEMORY_ERROR;
- stmt->errormsg = "Out of memory in SQLPutData (2)";
+ stmt->errormsg = "Out of memory in SQLPutData (2-2)";
SC_log_error(func, "", stmt);
return SQL_ERROR;
}
memcpy(current_param->EXEC_buffer, rgbValue, cbValue);
current_param->EXEC_buffer[cbValue] = '\0';
}
+ else
+ {
+ mylog("DataPut other cbValue = %d, rgbValue = %l d\n",current_param->buflen,*((SDWORD *) rgbValue));
+ current_param->EXEC_buffer = malloc(current_param->buflen);
+ if (!current_param->EXEC_buffer)
+ {
+ stmt->errornumber = STMT_NO_MEMORY_ERROR;
+ stmt->errormsg = "Out of memory in SQLPutData (2-3)";
+ SC_log_error(func, "", stmt);
+ return SQL_ERROR;
+ }
+ memcpy(current_param->EXEC_buffer, rgbValue, cbValue);
}
}
diff -iwaru postsrc-orig/results.c postsrc-patched/results.c
--- postsrc-orig/results.c Fri Mar 23 10:37:50 2001
+++ postsrc-patched/results.c Fri Mar 23 11:18:17 2001
@@ -154,20 +154,21 @@
if (!parse_ok)
{
+ /*
SC_pre_execute(stmt);
+ */
result = SC_get_Result(stmt);
mylog("SQLNumResultCols: result = %u, status = %d, numcols = %d\n", result, stmt->status, result != NULL ?
QR_NumResultCols(result): -1);
if ((!result) || ((stmt->status != STMT_FINISHED) && (stmt->status != STMT_PREMATURE)))
{
- /* no query has been executed on this statement */
- stmt->errornumber = STMT_SEQUENCE_ERROR;
- stmt->errormsg = "No query has been executed with that handle";
- SC_log_error(func, "", stmt);
- return SQL_ERROR;
+ stmt->nfld = 0;
+ *pccol = stmt->nfld;
}
-
+ else
+ {
*pccol = QR_NumResultCols(result);
+ }
}
return SQL_SUCCESS;
-------- Start patch (diff -iwaru postsrc-orig postsrc-patched) -------
Do you see any other problems?
Luf
> I apllied your tips and patch now looks: Sorry, I transfer it from 7.01.02 to current CVS and I make 2 fatal errors in bracket. I make diff again (with make_diff tools). Luf
Вложения
> -----Original Message-----
> From: Ludek Finstrle [mailto:xfinstrl@informatics.muni.cz]
>
> I apllied your tips and patch now looks:
>
> diff -iwaru postsrc-orig/execute.c postsrc-patched/execute.c
> --- postsrc-orig/execute.c Fri Mar 23 10:37:47 2001
> +++ postsrc-patched/execute.c Fri Mar 23 10:55:56 2001
> @@ -778,33 +778,46 @@
[snip]
> + else
> + {
> + mylog("DataPut other cbValue = %d,
> rgbValue = %l d\n",current_param->buflen,*((SDWORD *) rgbValue));
> + current_param->EXEC_buffer =
> malloc(current_param->buflen);
Does SQLPutData() come to this place in your test case ?
What is a real cbValue(the 3rd parameter of SQLPutData) ?
And how does the above mylog() display in reality ?
Are your paramters integers only ?
Reading SQLPutData's spec together with SQLBindParameter's
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.
regards,
Hiroshi Inoue
> > diff -iwaru postsrc-orig/execute.c postsrc-patched/execute.c
> > --- postsrc-orig/execute.c Fri Mar 23 10:37:47 2001
> > +++ postsrc-patched/execute.c Fri Mar 23 10:55:56 2001
> > @@ -778,33 +778,46 @@
>
> [snip]
>
> > + else
> > + {
> > + mylog("DataPut other cbValue = %d,
> > rgbValue = %l d\n",current_param->buflen,*((SDWORD *) rgbValue));
> > + current_param->EXEC_buffer =
> > malloc(current_param->buflen);
>
> Does SQLPutData() come to this place in your test case ?
Yes, it does.
> What is a real cbValue(the 3rd parameter of SQLPutData) ?
I don't test it. I try it and note a message.
> And how does the above mylog() display in reality ?
I think (not sure):
DataPut other cbValue = 4, rgbValue = 4
> Are your paramters integers only ?
Unfortunately yes.
> Reading SQLPutData's spec together with SQLBindParameter's
Where can I find these spec?
> 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.
Luf
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