missing String and/or File terminator RRS feed

  • Question

  • User-944707751 posted

    I am currently creating a VB.NET 2.0 WebService that takes in a Byte Array derived from 

    Dim nLength As Integer = CInt(FileUploader.PostedFile.InputStream.Length)
    Dim arrContent As Byte()
    ReDim arrContent(nLength)
    FileUpload.PostedFile.InputStream.Read(arrContent, 0, nLength)

    uploads that Byte() as a CSV file on my web server by

    Dim ms As New MemoryStream(arrFile)
    Dim fs As New FileStream(sFilePath, FileMode.Create)

    then converts the CSV file to a DataTable using the fast CsvReader assembly.

    My problem is that sometimes the last field in the last DataRow of my Datatable--which is type String--does not seem to be terminating. In the immediate window of VS, ?dr("ColumnName") gives < String: "blah blah > with no closing double quote. This causes my RegEx match to fail. If I go into the file and manually do a hard carriage return, everything works properly and querying in the immediate window shows the closing double quote. The core of my issue is that this is used in an ImportFile web application so I cannot guarantee a user will put a hard return at the end of the file. I've tried programmatically adding Environment.NewLine, vbcr, vbcrlf, etc. to the end of the file by appending to the file with StreamWriter.Write / StreamWriter.WriteLine once it is created with FileStream. I also tried assigning the Row Item to a variable with dr("ColumnName").ToString, and it still does not recognize it as a terminated String.

    Sorry for the lengthy explanation, but is there anything dumb I'm missing or doing along the way that would cause this? I can't seem to find anything too similar to my instance of the problem after a lot of searching. Someone solved a similar problem by stripping any "nulls" in the Byte() by clearing the 0's at the end. That didn't help me.

    Thanks in advance.

    Friday, July 16, 2010 6:59 PM

All replies

  • User-944707751 posted

    Nothing? Bump.

    Also... I think there's more to this than just "VB.NET".

    Monday, July 19, 2010 3:04 PM