[erlang-bugs] [Fwd: Re: odbc:param_query]
Ingela Anderton Andin
ingela@REDACTED
Fri May 9 10:36:38 CEST 2008
Hi!
After some further correspondence with the 64-bit patch maker (Willi)
the conclusion is that this is actually the patch for your problem.
@@ -1977,8 +1940,15 @@ static void init_param_column(param_array
*params, byte *
buffer, int *index,
static void init_param_statement(int cols, int num_param_values,
db_state *state, param_status *status)
{
+ int i;
+
status -> param_status_array =
(SQLUSMALLINT *)safe_malloc(num_param_values *
sizeof(SQLUSMALLINT));
+
+ for(i=0; i<num_param_values; i++) {
+ status -> param_status_array[i] = SQL_PARAM_PROCEED;
+ }
But if I understand him correctly there will still be a problem
with inserting more than one row with the MySql-driver. This is not a
problem with postgress or sql-server.
Willi says:
"Seems like mysql do not touch param_status_array at all,
and server bails out on garbage data when checking for SQLExec
termination status. As erlang-bugs reporter pointed, this is not the
only problem with mysql driver. I can confirm, when binding arrays mysql
picks only first value."
Regards Ingela Erlang/OTP Ericsson
Anders Nygren wrote:
> On Wed, May 7, 2008 at 2:34 AM, Ingela Anderton Andin
> <ingela@REDACTED> wrote:
>
>> Anders Nygren wrote:
>>
>>
>>> On Mon, May 5, 2008 at 8:01 AM, Anders Nygren <anders.nygren@REDACTED>
>>>
>> wrote:
>>
>>>
>>>> 2008/5/5 Ingela Anderton Andin <ingela@REDACTED>:
>>>>
>>>> >
>>>> > Hi!
>>>> >
>>>> > As a part of bigger patch (for 64 bit-odbc) I got the following
>>>>
>> change to
>>
>>>> > param-queries in odbcserver.c. This might help your case, it would
>>>> > be great if you could try that out for me. I am not very found of
>>>>
>> the ODBC
>>
>>>> > API (or the implementations of it anyway) it does surprising things
>>>> > at times.
>>>> >
>>>>
>>>> Hi Ingela
>>>> After a quick test, it looks like it is working fine with the patch.
>>>> Thanks a lot.
>>>>
>>>> /Anders
>>>>
>>>>
>>>>
>>> After some more testing I have seen that the problem remains.
>>>
>>>
>>>
>>>
>> Humm... could you be a little more specific? I guess that the problem
>> still occurs but
>> not as often?! (As you seemed to think that it helped at first.)
>>
>
> At first it failed most of the time, maybe 75%, but apparently randomly.
> After the patch I tested doing maybe 10 insert of one row each and
> all were successful. That was when I reported that the patch seemed
> to work.
> But later when I was testing another param_query it failed again. And
> also the original query started to fail again.
> I had originally said that even when I got the error the data was inserted.
> But that was not completely correct. If I try to insert one row it
> gets inserted.
> But if I try to INSERT several rows with one param_query and it gives the error
> only the first row is inserted.
>
> Unfortunately I do not have time right now to look into this in more detail,
> so I have just switched to using sql_query instead.
> Maybe I will be able to do some more tests in the beginning of June.
>
> /Anders
>
>
>> Maybe there are more special
>> cases that occur with the use of some drivers but not others. Alas we can
>> not test with all existing
>> drivers and all existing backends. We test with the databases
>> SQLServer on windows systems and Postgress on unix systems. When I get
>> time I will try to test with the table you supplied below in our
>> environment. But if the problem
>> is driver specific it might work just fine. (Our existing test on
>> param-queries does.)
>> Just a few questions, does it fail in a predictably way? Always the n:th
>> time you try or after you did something
>> elese or does it seem to be random? It would be good to have a minimal test
>> case to provoke the error.
>> Setting up a mysql-environment will however not be a top priority for us.
>> In the meantime if you should stumble on some solution yourself we will
>> of course accept patches a as long as they do not
>> break anything else and seem reasonable.
>>
>> Regards Ingela, Erlang/OTP Ericsson
>>
>>
>>
>>
>>>> > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte
>>>>
>> *buffer,
>>
>>>> > db_state *state)
>>>> > switch (param_status.param_status_array[i]) {
>>>> > case SQL_PARAM_SUCCESS:
>>>> > case SQL_PARAM_SUCCESS_WITH_INFO:
>>>> > + case SQL_PARAM_DIAG_UNAVAILABLE:
>>>> > break;
>>>> > default:
>>>> > diagnos =
>>>> >
>>>> >
>>>> > Regards Ingela - OTP team
>>>> >
>>>> > Anders Nygren wrote:
>>>> >
>>>> > > I am having a problem with parameterized queries
>>>> > > Erlang R12B-2 on Linux (SuSE 10.3)
>>>> > > MySQL 5.0.45
>>>> > > myodbc 3.51
>>>> > > unixODBC 2.2.12
>>>> > >
>>>> > >
>>>> > > Reply = odbc:param_query(State#state.cref,
>>>> > > "insert into Users (userId, password, "
>>>> > > "userType, name) values (?,?,?,?)",
>>>> > > [{{sql_varchar,20},[UserId]},
>>>> > > {{sql_varchar,20},[Passwd]},
>>>> > > {{sql_char,6},[Type]},
>>>> > > {{sql_varchar,100},[Name]}]),
>>>> > >
>>>> > >
>>>> > > Sometimes I get {updated, 1}, but most of the time I get the
>>>>
>> following
>>
>>>> > error
>>>> > > {error,"No SQL-driver information available."} but the data has
>>>>
>> been
>>
>>>> > inserted.
>>>> > >
>>>> > > The table is created with
>>>> > > CREATE TABLE IF NOT EXISTS `npas`.`Users` (
>>>> > > `userId` VARCHAR(20) NOT NULL ,
>>>> > > `password` VARCHAR(20) NOT NULL ,
>>>> > > `userType` ENUM('admin','normal','read') NOT NULL ,
>>>> > > `name` VARCHAR(100) NOT NULL ,
>>>> > > PRIMARY KEY (`userId`) )
>>>> > > ENGINE = InnoDB
>>>> > > PACK_KEYS = 0
>>>> > > ROW_FORMAT = DEFAULT;
>>>> > > _______________________________________________
>>>> > > erlang-bugs mailing list
>>>> > > erlang-bugs@REDACTED
>>>> > > http://www.erlang.org/mailman/listinfo/erlang-bugs
>>>> > >
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > erlang-bugs mailing list
>>>> > erlang-bugs@REDACTED
>>>> > http://www.erlang.org/mailman/listinfo/erlang-bugs
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
More information about the erlang-bugs
mailing list