freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] FreeTDS and buffering on client side
- From: Frediano Ziglio <freddy77 AT gmail.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] FreeTDS and buffering on client side
- Date: Thu, 26 Oct 2017 09:20:09 +0100
2017-10-26 7:14 GMT+01:00 LacaK <lacak AT zoznam.sk>:
> Thank you very much Frediano,
>
> now , when I increase number of rows in table I can reproduce network
> failure.
>
> But behavior is other than I have expected.
>
> I was expecting, that dbnextrow() will return FAIL, but it seems, that call
> to dbnextrow() never returns ... it freezes somewhere in dblib.dll
> (I can not debug more because I use dblib.dll from Pascal program)
>
> Is it expected behavior?
>
> L.
>
No, should return an error.
TDSDUMP could help.
Frediano
>> 2017-10-25 11:38 GMT+01:00 LacaK <lacak AT zoznam.sk>:
>>>
>>> Hi *,
>>>
>>> I would like to ask how FreeTDS performs buffering on client side.
>>> I use dblib as my client library (I do not set there DBBUFFER using
>>> "dbsetopt")
>>>
>>> I am trying simulate network failure in such way:
>>> 1. connect to MS SQL Server using dbopen()
>>> 2. I send SQL select using dbcmd(), dbsqlexec()
>>> 3. then I call dbresults()
>>> 4. here I pause program and unplug network cable to simulate network
>>> error
>>> 5. next I process rows in loop calling dbnextrow()
>>>
>>> Strange thing is that I can perform step 5 also when network cable is
>>> unpluged. So I have suspection, that all rows from select are already
>>> somewhere on client side. Probably handled already by underlaying libtds
>>> ?
>>>
>>> What is going to happen? Why I can still read rows when there is already
>>> broken network connection ?
>>> Thanks
>>>
>>> -Laco.
>>>
>> There are a lot of caching in between.
>> The server execute the query and starts sending back results.
>> Probably the results you are expecting are already sent by the server
>> when you disconnect the cable and are in the tcp socket buffer ready
>> to be parsed from your program. Try to return 1000000 rows and at
>> some point the program will fail (unless connection is really fast and
>> network buffer is big enough!).
>>
>> Frediano
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> https://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> https://lists.ibiblio.org/mailman/listinfo/freetds
-
[freetds] FreeTDS and buffering on client side,
LacaK, 10/25/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Frediano Ziglio, 10/25/2017
-
Re: [freetds] FreeTDS and buffering on client side,
LacaK, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Frediano Ziglio, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
LacaK, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Craig Jackson, 10/26/2017
- Re: [freetds] FreeTDS and buffering on client side, Frediano Ziglio, 10/30/2017
-
Re: [freetds] FreeTDS and buffering on client side,
LacaK, 10/27/2017
- Re: [freetds] FreeTDS and buffering on client side, Frediano Ziglio, 10/29/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Peter Deacon, 10/29/2017
- Re: [freetds] FreeTDS and buffering on client side, Frediano Ziglio, 10/30/2017
- Re: [freetds] FreeTDS and buffering on client side, LacaK, 10/31/2017
- Re: [freetds] FreeTDS and buffering on client side, Frediano Ziglio, 10/31/2017
- Re: [freetds] FreeTDS and buffering on client side, LacaK, 10/31/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Craig Jackson, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
LacaK, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Frediano Ziglio, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
LacaK, 10/26/2017
-
Re: [freetds] FreeTDS and buffering on client side,
Frediano Ziglio, 10/25/2017
Archive powered by MHonArc 2.6.24.