A stored procedure was returning 1 row in query analyzer, 2 in DBI. 

This warning was shown in query analyzer: 
  Warning: Null value is eliminated by an aggregate or other SET operation

After setting $dbh->trace(15)

<code>
      SQLFetch rc 0
    dbih_setup_fbav for 7 fields => 0x9c9d05c
fetch num_fields=7
fetch col#0 mailing_num datalen=1 displ=12
fetch col#1  datalen=10 displ=31
fetch col#2 total datalen=1 displ=12
fetch col#3 new datalen=1 displ=12
fetch col#4 revised datalen=1 displ=12
fetch col#5 total_ref datalen=1 displ=12
fetch col#6 documents datalen=1 displ=12
       SQLFetch rc 1
fetch num_fields=7
fetch col#0 mailing_num datalen=1 displ=12
fetch col#1  datalen=10 displ=31
fetch col#2 total datalen=1 displ=12
fetch col#3 new datalen=1 displ=12
fetch col#4 revised datalen=1 displ=12
fetch col#5 total_ref datalen=1 displ=12
fetch col#6 documents datalen=1 displ=12
       SQLFetch rc 100
</code>

rc0 = success, rc1 = success with info, rc100 = no data found

success with info means a warning.

It isn't clear whether the problem is occuring because the odbc driver (libiodbc) provides an extra row of data,
or that it occurs due to DBD::ODBC misbehaving. Further research is neccesary.

Since Query analyzer handles this correctly it is safe to say that SQL Server is behaving itself.
So the next step is probably to install another utility that can use libiodbc (perhaps use a python library) and see if it
experiences the same issus.



A workaround is to include this command before the select statement that causes a warning:
SET ANSI_WARNINGS OFF