FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Brian Johnson wrote:
> 
> Let me start by saying that the following numbers are somewhat made up,
> but demonstrate the problem accurately.  Anyway, lets say we have a
> table with 5 columns, and 100 rows.  If we do a "select * from foo", we
> would expect to get 100 rows returned.  We don't.  Instead we get say 25
> rows, and the select hangs.  I can print out the results of those 25
> rows in perl, but the 26th row never gets returned.
> 
> So, we modified the select to be "SELECT col1 FROM foo", and we got all
> 100 rows of that column.  So we did "SELECT col1, col2 FROM foo", and
> then we got 75 rows and it hung.  So we tried "SELECT col1, col2, col3"
> FROM foo", and ended up getting 50 rows.
> 
> Of course, the numbers were not so nice and round.  As for how we are
> connecting, I have tried DSN and DNS-less connections with dbi::ODBC,
> and of course have tried with sqsh.  For sqsh I added an entry to
> freetds.conf, and then ran sqsh -S ENTRYNAME -U USER -P PASS.  I was
> able to do very small selects, but any time I did a select that returned
> large numbers of rows it hung.

There's nothing in FreeTDS that would explain what you're seeing.  It sure
sounds to me like there's something on your network -- perhaps a firewall?
Some sort of traffic shaper? -- between you and your server.   

You can use TDSDUMP to create a log of the session and show it to your
network folks.  I think you'll see the server seems to stop sending in
mid-packet.  If you can show a successful log with the old server, that
might convince them to track it down.  

HTH.  

--jkl