views:

128

answers:

4

Solution:

It turns out I wasn't checking the path that it was looking up, quite silly of me. Once I tracked that problem down and corrected the offending path, the reading worked just fine. Still baffled at the MSSQL issue, since the articles average less than 10 000 bytes.


Clarification:

I am unsure if some of you are under the impression that the file I am trying to read is on my local machine. It resides on the web, on the same server as the script that is accessing it. Just in a different directory.


I wrote an online help desk application that includes articles. One problem I have run into is some of the articles are too long, and get truncated when I put them into my MSSQL database. I tried using TEXT and VARCHAR(MAX) as the data type, but it would still get truncated.

So I decided that I would put the articles that are too long into a text file, and have my application read the text file from there. I got this code working in my development environment, but it does not work live:

Dim output As String = String.Empty
Try
 Dim theArticle As gsClassroom = classArticles(iterate)
 If theArticle.Body.StartsWith("/docs/") Then
  Dim oReader As IO.StreamReader = Nothing
  Try
   oReader = New IO.StreamReader(Server.MapPath(String.Format("/dev{0}", theArticle.Body)))


  Catch ex As Exception
   output = String.Format("{0}<br /><br />{1}", ex.Message, "internal")
  Finally
   oReader.Close()
   oReader.Dispose()
   oReader = Nothing
  End Try
 Else
  output = theArticle.Body
 End If
Catch ex As Exception
 output = String.Format("{0}<br /><br />{1}", ex.Message, "external")
End Try
Response.Output.WriteLine(output)

At first, I thought it was because I did not change the /dev path prefix to /hlpdsk. But even after I changed it, it bombed out. What am I doing wrong?

+2  A: 

The first thing that enters my mind on these sorts of issues is permissions settings on your production environment won't allow you to access that directory.

Matthew Vines
+1  A: 

I know you want to solve the issue of reading this text file, but I would suggest that you go back to reading the text from the sql server table with Varchar(MAX).

Please note that when text is larger than a few KB it splits it down to several results. So when reading you would have to read from datareader and write to a string builder. When done then you would have the full content in the string builder.

As for the file reading don't do it. It would have a lot of file permission issues in the server environment.

Shafqat Ahmed
You would have to call the reader.NextResult() method to get the next part of the string that is split by the data reader
Shafqat Ahmed
+1  A: 

What kind of helpdesk articles are more than 2^31-1 bytes long? (The limit of varchar(max))

An article that long would take so long to load that people would assume the web site is broken and give up. Wouldn't it?

Licky Lindsay
They aren't that incredibly long, which is what weirds me out too.
Anders
+1  A: 

The reason it failed is permissions, just as Matthew says. When you develop in VS, you typically run using the integrated Visual Studio web server. When running this web server, it's running under the permissions of your logged-in account, which means you've got access to pretty much everything on your local PC.

When you deploy to production, you're running in IIS, and the security permissions are that of the Application Pool that your app happens to be running in. By default, an AppPool runs under the NetworkService account, which means it has minimal access to local resources on your PC.

You can elevate the permissions of the AppPool, but this is a bad practice and a security risk. A much better approach, as has already been stated, is to properly use the data types available in SQL Server to store your data.

ChrisW