StreamWriter appears to stop writng after 100 chars

I am writing a little utility to generate some SQL files. I have a file which is generated from a string array of 400+ elements. It stops writing (without throwing an error) at arround 1000 characters or 380 lines. I am clearly missing something here. Question is what? I've tried (the remed lines of) flush but that seems to have no effect.

<code>
Dim fsExec As New FileStream(sPath & sExecFileName & ".sql", FileMode.Create, FileAccess.Write)
'declaring a FileStream and creating a document file with
'access mode of writing
Dim sExec As New StreamWriter(fsExec)

Dim iChar As Integer = 0
For icount = 0 To miExecLineCount
iChar += msExec(icount).Length
If icount = 382 Then
icount = icount
End If
'writing text to the newly created file
sExec.WriteLine(msExec(icount))
'If icount Mod 100 = 50 Then
' sExec.Flush()
' fsExec.Flush()
'End If
lblMessage.Text = msExec(icount)
lblMessage.Refresh()
Application.DoEvents()
Next
</code>

First up, please use the Code or VBCode button provided to wrap your code snippets in tags for readability. You appear to have tried to do it by hand but you have used chevrons <> instead of brackets [].

As for your code, I would first suggest that this:

Code:

---

Dim fsExec As New FileStream(sPath & sExecFileName & ".sql", FileMode.Create, FileAccess.Write)
'declaring a FileStream and creating a document file with
'access mode of writing
Dim sExec As New StreamWriter(fsExec)

---

Can be more succinctly written like this:

Code:

---

Dim sExec As New StreamWriter(sPath & sExecFileName & ".sql")

---

There's no need for you explicitly create a FileStream when the StreamWriter can create one implicitly. Also, you should create short-lived, disposable object with a Using statement:

Code:

---

Using sExec As New StreamWriter(sPath & sExecFileName & ".sql")
    '...
End Using

---

That ensures that the object gets disposed, even if an unhandled exception occurs. In the case of a StreamWriter, that means that the file will be closed implicitly when you're done with it.

As for the issue, have you debugged your code? Have you stepped through it line by line to see exactly what it does? That is what you should be doing. Get rid of all the extraneous code (which you shouldn't have posted here because it simply distracts us from the issue) and place a breakpoint (using F9) at the top of the code. When execution breaks, you can step line by line (using F10) and check at each step what you expect to happen and what actually did happen. You can even right click the breakpoint and add a condition. That would allow you to, for instance, only break when the loop counter gets to 375.

Applogies for the code braces.

Quote:

---

As for the issue, have you debugged your code? Have you stepped through it line by line to see exactly what it does? That is what you should be doing.

---

Well the original question contained the phrase "without throwing an error" and I have stepped through the code, it does exactly what it is supposed to do. The element which is part written and the subsequent elements which are not witten to physical file are processed in exactly the same way as the ones which are (from a debug point of view).

Sounds like you a might have a null byte or some other spurious data. Once the data has been written, identify exactly where it appears to end. Run the code again and check exactly what data occurs at that area. Check the actual byte values.

Dont think it is a null byte. The writing stops mid line and the line is nothing special.

however

Code:

---

Dim oWrite As New System.IO.StreamWriter(sPath & sExecFileName & ".sql")
For icount = 0 To miExecLineCount
    'writing text to the newly created file
    oWrite.WriteLine(msExec(icount))
    lblMessage.Text = msExec(icount)
    lblMessage.Refresh()
    Application.DoEvents()
Next
oWrite.Close()

---

works without fail - so why explicitly declaring fails and implicit works?