Skip to Content.
Sympa Menu

freetds - Re: [freetds] Output bufferring

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] Output bufferring
  • Date: Fri, 15 Apr 2016 16:02:54 +0100

2016-04-14 8:18 GMT+01:00 <jezekj AT centrum.cz>:
> Hello,
>
> we have following issue. In our application we're tring to match securities
> with our internal ID based on couple of international IDs. Securities are
> comming from different data providers during the night. We do have a
> procedure which is trying to match data from these feeds. This procedure is
> writen to iterate over period of time. At every iteration it prints out
> statistics about how many securities were matched, and how many securities
> has not matched, because data from external providers are missing.
> Everything works fine with MSSQL Studio and even with isql from freetds.
> However when we call out the procedure from our perl environment. Output is
> bufferred and this buffer is flushed when procedure finishes. We have tried
> tracing on several levels and we have found that in FreeTDS trace log
> messages are written at every itteration. However in UnixODBC trace
> messages are shown when procedure finishes.
>
> Question is very easy. Who is the trouble maker? Is freeTDS bufferring
> messages on it's output (but after tracing log is written), or are these
> messages buffered in the UnixODBC?
>
> If you wish to reproduce, just let me know and I will prepare sproc for you.
>
> Thanks for your time & support.
> Jakub


I think what you are looking for is SET NOCOUNT option.

A bit of explanation. SQL Server during command (SELECTs, UPDATEs and
so on) send back number of row processed. Even during store procedure!
So even a simple command like "SELECT @var = 123" by default send back
the number of rows (in this case 1). Disabling the option reduce the
data sent back. For the SELECT case above you can also use SET
instead.
I would also suggest to use less queries and more join but not knowing
the code I could not suggest anything in particular.

Hope I guessed your problem.

Frediano




Archive powered by MHonArc 2.6.24.

Top of Page