recordset data getting truncted during response.write

I have an ASP app that we've moved from a Windows 2000 to a Windows
2003 server (sql server 2000 to sql server 2005). The job runs fine on
the old servers.

Part of the app takes a recordset and response.writes out comma
delimited strings so that the results are opened in Excel or saved to a
flat file.

Basically, it looks something like this like this:

Response.AddHeader
"Content-Disposition","attachment;filename=Report.csv"
Call WriteHeader() ' Write out the headers for the columns below
For i = 1 to Ubound(arrRS, 2)

Response.write """" & arrRS(arrPONumber, i) & """" & ","
Response.write arrRS(arrRevNumber, i) & ","
Response.write """" & arrRS(arrPOStatusDesc, i) & """" & ","
Response.write """" & arrRS(arrLicName, i) & """" & ","
Response.write arrRS(arrOrderDateStamp, i) & ","
Response.write arrRS(arrOrderDate, i) & ","
Response.write arrRS(arrBuyCycleStamp, i) & ","
Response.write arrRS(arrShipDate, i) & ","
Response.write arrRS(arrConfShipDate, i) & ","
Response.write arrRS(arrCurrShipDate, i) & ","
Response.write arrRS(arrSD, i) & ","
Response.write vbCrLf
Next

When we moved it over to the new servers, the job started to have
problems. If I run the underlying sproc in sQL Server,
it returns about 17K records. If I run it in the ASP app, it only pulls
back about 2K records and the header section at the top is missing.

When I run it in the ASP page, I seem to only get the last X number of
records. It's like it sends out the first large chunk of records,
throws them away and then displays what's remaining.

If I changed the job to only show records 1 - 10000, it's fine.

If I change it to show records 1 - 10718, it's fine.

If I show 1 - 10719 records it craps out and only shows 2 rows of data
and no header.

If I show 1000 - 11718, it's fine.

I commented out all columns and started adding them back in, but I
can't identify a single column that's causing the problems.

I've cached the Responses and used Response.flush.

I changed the timeout on the IIS server to 900 (same as the old server)
with no love. I don't see any information indicating a maximum amount
of bytes that can be sent anywhere.

What the heck?? Any other ideas you might have would be appreciated.

Re: recordset data getting truncted during response.write

cbtechlists@gmail.com wrote:
> I have an ASP app that we've moved from a Windows 2000 to a Windows
> 2003 server (sql server 2000 to sql server 2005). The job runs fine on
> the old servers.
>
> Part of the app takes a recordset and response.writes out comma
> delimited strings so that the results are opened in Excel or saved to
> a flat file.
>
> Basically, it looks something like this like this:
>
> Response.AddHeader
> "Content-Disposition","attachment;filename=Report.csv"
> Call WriteHeader() ' Write out the headers for the columns below
> For i = 1 to Ubound(arrRS, 2)
>
> Response.write """" & arrRS(arrPONumber, i) & """" & ","
> Response.write arrRS(arrRevNumber, i) & ","
> Response.write """" & arrRS(arrPOStatusDesc, i) & """" & ","
> Response.write """" & arrRS(arrLicName, i) & """" & ","
> Response.write arrRS(arrOrderDateStamp, i) & ","
> Response.write arrRS(arrOrderDate, i) & ","
> Response.write arrRS(arrBuyCycleStamp, i) & ","
> Response.write arrRS(arrShipDate, i) & ","
> Response.write arrRS(arrConfShipDate, i) & ","
> Response.write arrRS(arrCurrShipDate, i) & ","
> Response.write arrRS(arrSD, i) & ","
> Response.write vbCrLf
> Next
>
> When we moved it over to the new servers, the job started to have
> problems. If I run the underlying sproc in sQL Server,
> it returns about 17K records. If I run it in the ASP app, it only
> pulls back about 2K records and the header section at the top is
> missing.
>
> When I run it in the ASP page, I seem to only get the last X number of
> records. It's like it sends out the first large chunk of records,
> throws them away and then displays what's remaining.
>
> If I changed the job to only show records 1 - 10000, it's fine.
>
> If I change it to show records 1 - 10718, it's fine.
>
> If I show 1 - 10719 records it craps out and only shows 2 rows of data
> and no header.
>
> If I show 1000 - 11718, it's fine.
>
> I commented out all columns and started adding them back in, but I
> can't identify a single column that's causing the problems.
>
> I've cached the Responses and used Response.flush.
>
> I changed the timeout on the IIS server to 900 (same as the old
> server) with no love. I don't see any information indicating a
> maximum amount of bytes that can be sent anywhere.
>
> What the heck?? Any other ideas you might have would be appreciated.

I assume you've verified via Response.Write Ubound(arrRS, 2)
that the array (I assume you are generating it via GetRows) contains the
expected number of records.

I would use fso to write this data to a file on the server so you can
get some clues from it. You might want to consider streaming the file to
response instead of directly writing the data to Response.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: recordset data getting truncted during response.write

Hi Bob:

Bob Barrows [MVP] wrote:> >
> I assume you've verified via Response.Write Ubound(arrRS, 2)
> that the array (I assume you are generating it via GetRows) contains the
> expected number of records.

Yes, I'm using GetRows, and the array does contain the proper number of
records.

> I would use fso to write this data to a file on the server so you can
> get some clues from it. You might want to consider streaming the file to
> response instead of directly writing the data to Response.

I did this and the file created looks fine. Is there some kind of
limitation on the Response.Write method and IIS6? Why would this work
on the old server and not the new?

I'll try the streaming bit and let you know if that works.

Thanks!

Chris

Re: recordset data getting truncted during response.write

cbtechlists@gmail.com wrote:
> Hi Bob:
>
> Bob Barrows [MVP] wrote:> >
>> I assume you've verified via Response.Write Ubound(arrRS, 2)
>> that the array (I assume you are generating it via GetRows) contains
>> the expected number of records.
>
> Yes, I'm using GetRows, and the array does contain the proper number
> of records.
>
>> I would use fso to write this data to a file on the server so you can
>> get some clues from it. You might want to consider streaming the
>> file to response instead of directly writing the data to Response.
>
> I did this and the file created looks fine.

So we've successfully eliminated data corruption. I suppose you've tried
browsing to the file you created to ensure that you can at least do
that.

> Is there some kind of
> limitation on the Response.Write method and IIS6?

None that I know of. There IS a limit on the size of the Request that
can be adjusted, but I've never seen a limit on the size of the
Response.

> Why would this work
> on the old server and not the new?

Got me. Sorry.
>
> I'll try the streaming bit and let you know if that works.
>
Good luck.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: recordset data getting truncted during response.write

cbtechlists@gmail.com wrote:
> I did this and the file created looks fine. Is there some kind
> of limitation on the Response.Write method and IIS6?

There *is* a metabase value AspBufferingLimit that could be the culprit, but
it seems to me you should get the "response buffer limit exceeded" exception
rather than a truncated table.

Since you appear to get all of the data, try flushing the buffer with each
pass through the recordset:

> Response.write arrRS(arrSD, i) & ","
> Response.write vbCrLf
Response.Flush ' <--- Right here ---
> Next



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.