Here's an example to replicate the situation. We'll generate a table with multiple rows of the alphabet and email the contents:

This should kick out the alphabet repeated 256 times, with a <br> tag after each alphabet. By examining the result in query analyzer, it should look just fine. However, when you go check the email that got sent, you'll find parts of the text that look like this:

abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzabcdef! ghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
.
.
.
abcdefghijklmnopqrstuvwxyz
abcd! efghijklm! nopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz

Fortunately, the solution is fairly simple. Microsoft Outlook seems to insert these exclamation marks randomly throughout the email when the mail contains no line feeds.

So, stick a line feed after each alphabet and the exclamation marks will disappear from the email:

Piece of cake

When accessing an SQL stored procedure in ASP via ADO, it is typically considered best practice to use the command object:

If the stored procedure returns a recordset, then the Execute() method of the command object will return a recordset object.

Consder the following stored procedure:

Using a command object set up to call this procedure, we can access the returned recordset like so:

If a stored procedure returns a return value, then a return value parameter is required on the ADO command object.

Consider the following procedure:

To retrieve the return value in the stored procedure, you have to set up a parameter on the command object to store the return value:

Now, things get a little tricky if you have a recordset and a return value in the same procedure:

The recordset object will be populated correctly, but the return value parameter returns "undefined":

One thing that may seem even more odd is that if you do not assign the recordset returned by the procedure to a variable (oRS in the example above), then the returnValue parameter contains the correct value.

The reason for this is that the recordset returned by the stored procedure must be closed before you can access the returnValue parameter. I find using the GetRows() method to be extremely handy for this as it allows you to pull all the recordset information into an ASP array and close the recordset immediately afterward, giving you access to both the recordset information and the return value at the same time.

For a long time I have had to make web reports for our company that could be exported to excel. This is a fairly easy process. All you have to do is put your report in an HTML table and add the following 2 lines of code:

However, when the excel file is generated it has a nasty side effect of having all the gridlines hidden. They can easily be turned back on in excel by the following: Tools > Options > click gridlines checkbox.

Until today I put up with the gridlines being hidden. When I tried to search for a solution via google, most people suggested that it just wasn't possible to generate the excel report with gridlines. Other people offered solutions that required you to run a COM object on the server to start an instance of excel in the background to create the file. However, after searching through a bunch of garbage and piecing together bits and pieces of non-working solutions, I finally got it to work. The trick is to set up your own custom XML settings, and add the "Panes" worksheet option. Here was the working solution:

Got a web related question? Discuss it in the forums: http://forum.lessthandot.com/