• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

ASP display carriage returns

Homerboy

Lifer
I have a simple .asp page pulling data from SQL table.

The field value contains carraige returns (if I pull a query in text via SSMS, it displays the carriage returns for that field).

my .asp code is simply:

<td><%Response.Write(rs.fields("revision_desc"))%></td>

which, as you know will NOT display the carriage returns, and show the resultant string value in a single row of text.

What's the proper syntax to get that code to display the carriage returns?

Thanks in advance.
 
The closest html equivalent to the carriage return is the <br /> tag. So the simplest solution would be to scan through the string and replace the carriage returns with that tag.

However, it can get a little complicated, because what is a carriage return? Historically a carriage return simply moved the print head back to the left margin. To get it to the next line you also needed a newline character. That's why you still see "\r\n" used in C# and C++ to represent a carriage return. Return + newline. The defaults are different on windows and Linux, and you'd have to look at the strings in the db to see if they contained "\r," "\n," or both.

Fortunately .NET includes a class called Environment, which has a static property called NewLine that is set to the default new line string for the platform. So you should be able to do this:

<td>
<%Response.Write(rs.fields("revision_desc".Replace(Environment.NewLine, "<br />")))%>
</td>
 
I actually tried a line pretty much identical to that.
however it throws an error when the page attempts to load.

Looking at the string in the db, it actually doesn't SHOW any \r or \n

I will admit (if you haven't figure it out already) I'm a tad of a newbie on this stuff.

(thanks for the detailed response by the way!)
 
Since you are using asp I would use the replace function to replace any newline (vbNewLine constant) or control feed (vbCrlf constant) with the html linebreak tag <br />

<td><%Response.Write(Replace(rs.fields("revision_desc"), vbCrLf, "<br />"))%> </td>
 
The escape codes may very well not be displayed by whatever tool you're using to look at the strings. Best thing to do would be to paste them into a text editor, or even better look at them in a hex dump so you can see the actual codes. If you don't see any 0x0a, 0x0d or some combination, then there are no carriage returns (if the string is encoded using wide characters you'll see 0x0 bytes between those codes, otherwise not).

Other than that it would be hard to say what's going on without seeing some more code or context.
 
Since you are using asp I would use the replace function to replace any newline (vbNewLine constant) or control feed (vbCrlf constant) with the html linebreak tag <br />

<td><%Response.Write(Replace(rs.fields("revision_desc"), vbCrLf, "<br />"))%> </td>

i actually did this one earlier as well (thank you google!).
While it does not throw an error and displays the data, it is still in a single line of text 🙁
 
when I copy my text from a SSMS query into a text editor (notepad++), it shows the carriage returns being [CrLf]
If that helps any....
 
you could also try the <pre> tag, which was meant for exactly this purpose. Any text inside of pre tag will retain carriage returns, as well as any other formating HTML omits, such as tabs.
 
you could also try the <pre> tag, which was meant for exactly this purpose. Any text inside of pre tag will retain carriage returns, as well as any other formating HTML omits, such as tabs.

Good point!
 
Sorry guys, just getting back to this issue now.

I tried

<pre><td><%Response.Write(Replace(rs.fields("revision_desc"), CrLf, "<br />"))%> </td></pre>

But it still returns a single line.
This is driving me nuts.
 
bloody hell... This is why you need to walk away from things once in a while and take a breather.

<td><pre><%Response.Write(rs.fields("revision_reason"))%></pre></td>

That works fine!
Anyone notice the difference?
 
now... how do I replace a blank text box with null instead of blank (it's updating a date field in the SQL table thus creating "01-01-1900" and not NULL
 
It allows NULLs, is set to "DATE" datatype and there is no default.
From my understanding the default value for a textbox in ASP is "".
When "" is inserted into a DATE datatype it translates to "01-01-1900"
 
hmm, I've never had that problem. Though its been a while since I did regular ASP.Net (doing MVC now, which converts empty strings to nulls by default)

Is this MS SQL? Seems weird to use 1900 as the default as the minimum date is actually "01-01-1753" or "01-01-0001" for DateTime2
 
well the other way to do this is just to leave it in the db as "01-01-1900"
then in the display, convert "01-01-1900" to ""

...trying to figure that out now.
I can "cheat" at this and make it sloppy as it's really just for a small internal webapplication
 
Conventions when dealing with DateTimes are not uncommon. It's notorious for being the most difficult data type to work with.
 
Ok, now I just cheated more:



CREATE TRIGGER NULL_DATES
ON CLS_CODES
FOR INSERT
AS
Begin
Update CLS_CODES set REMOVED_DATE = NULL where REMOVED_DATE = '1900-01-01'
Update CLS_CODES set REVISION_DATE = NULL where REVISION_DATE = '1900-01-01'
Update CLS_CODES set CREATION_DATE = NULL where CREATION_DATE = '1900-01-01'
End
 
well the other way to do this is just to leave it in the db as "01-01-1900"
then in the display, convert "01-01-1900" to ""

...trying to figure that out now.
I can "cheat" at this and make it sloppy as it's really just for a small internal webapplication

Within your database/DAL layer you need to convert "" to null and store null in the database. If this app grows you don't want to have a million references to 1/1/1900 within your SQL and asp code. I say this from experience, as Great Plains, our HR package, defaults null dates as 1/1/1900 and it can make reporting very annoying.

When building your SQL query use the NULLIF function like: Field=NULLIF(@Param,'')

See:
http://forums.asp.net/t/1481494.aspx/1?Changing+1+1+1900+to+Blank
 
Back
Top