Re: affected rows after insert

Frediano Ziglio <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <CAHt6W4dp1C2Yg+DcTv=gPkKiSpNfFbc4V1npnBM=Jy_WHgR-RA@mail.gmail.com>
2015-10-19 11:16 GMT+01:00 David Nichols <[email protected]>:
>
>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio <[email protected]> wrote:
>>
>> 2015-10-16 12:23 GMT+01:00 David Nichols <[email protected]>:
>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek <ondrej.holecek at qoretechnologies.com <http://lists.ibiblio.org/mailman/listinfo/freetds>>:
>>>>> 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
>>> Hi,
>>>
>>> Ondra has not been working on this for quite some time, but I’d like to pick up this issue again please.
>>>
>>> We are using MS SQL Server 2008 - using tds version = 7.2  - with the patch we are able to get the affected rows reliably - without it, we are not.
>>>
>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0)
>>>
>>> I would be happy to continue helping with this issue if there’s a chance it could be included in freetds (or some other equally effective fix).
>>>
>>> thanks,
>>> David
>>>
>>
>> A fix was written for this case. Do you still have some code that
>> fails? Did you update FreeTDS?
>>
>> Frediano
>
> yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed.  Sorry I did not mention this in the original email.
>

Please try a more recent version (like 0.95.21). Also you should sent
some extract of your tests. Can you post an updated patch?

> BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux
>

Quite odd. Could be you miss some package on your system. Which error
did you get? Could be you have an old autoconf package.

Frediano

> thx
> David
>
>
>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek
>>>>> <ondrej.holecek at qoretechnologies.com <http://lists.ibiblio.org/mailman/listinfo/freetds>> 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
>>>
>>>
>>> _______________________________________________
>>> FreeTDS mailing list
>>> [email protected]
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.