Skip to Content.
Sympa Menu

freetds - Re: [freetds] affected rows after insert

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] affected rows after insert
  • Date: Thu, 11 Jun 2015 22:28:45 +0100

2015-06-09 14:48 GMT+01:00 Ondrej Holecek
<ondrej.holecek AT qoretechnologies.com>:
> Hi,
>
> I made a test with the same code but sybase lib and it works like
> expected. It seems there is a bug in FreeTDS. Could you please check
> my patch?
>
> thx,
>
> Ondrej
>

Actually works and ctlib tests seems to pass.

However DONEINPROC is returned in a lot of cases, for instance if
database execute some trigger on the table so your patch can catch
some strange results too.

Which database version are you using?

Frediano

> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek
> <ondrej.holecek AT qoretechnologies.com> wrote:
>> Hi,
>>
>> I have a problem obtaining number of affected rows while inserting.
>> The problem occurs when I pass the values by ct_param() call.
>> So, this command order works well:
>>
>> ct_cmd_alloc()
>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)")
>> ct_send()
>> ct_result() // the result type is CS_CMD_DONE so I can call...
>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected
>>
>>
>> but when I call it like this, It skips CS_CMD_DONE, so I can't read
>> the affected rows number.
>>
>> ct_cmd_alloc()
>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)")
>> ct_param("@par1", 1)
>> ct_send()
>> ct_result() // the result type is CS_END_RESULT
>> // can't do anything here :-(
>>
>>
>> The row is inserted in both cases correctly just in the second case I
>> can't read the number of affected rows.
>>
>> I did some ctlib debugging and I created the patch which would fix
>> this behavior. However, I just changed the code blindly (based on the
>> debugging) not knowing what is the real purpose of the case.
>>
>>
>> in ct_result() function I changed the case _CS_RES_INIT:
>>
>> case _CS_RES_INIT: /* commalindlnd had no result set */
>> if (tds->rows_affected > 0) {
>> *result_type = CS_CMD_DONE;
>> cmd->results_state = _CS_RES_INIT;
>> return CS_SUCCEED;
>> }
>> break;
>>
>> now it seems with the patch it works correctly. But I have no idea if
>> it is really the correct way.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Ondrej




Archive powered by MHonArc 2.6.24.

Top of Page