Programming & Web Design

Recently, I had to do some home .Net development (I mainly do .Net work only at ... work), but when I had some Internet issues and had to work offline, I loaded up my copy of Visual Studio 2008. I opened up my web project and everything seemed to be working fine until I tried to switch to design view on any page or control. Once I tried going to Design View, Visual Studio would stop responding and only a forced quit would close the application. Here's the environmental settings I was working with -

• Windows Vista Ultimate 64-bit Edition
• Visual Studio 2008 Service Pack 1
• Microsoft Office 2010 64-bit

Nothing out of the ordinary as you could see. Obviously, whenever I run into a problem like this, I load up a search engine and search for a solution and found quite a few complaints about this problem. However, after reading the "de facto" solution post from Microsoft, I felt as if I needed to more accurately spell out how to fix this problem since I only found the correct solution after reading through several posts.

1. Close Visual Studio.
2. Open up your Control Panel.
3. Go to your installed Programs and Features.
4. Look for an entry called Microsoft Visual Studio Web Authoring Component.
5. Right click on this entry.
6. Choose Change.
7. Select the option to Repair.
8. Re-open Visual Studio and try using design view in your web application.

Obviously, if you don't have this program, you need to install it. Fixing this problem, for me, was really that simple while other posts talked about editing your registry key for Office LastProduct, making sure you had Visual Studio SP1 installed, etc. However, I found that this was the easiest solution that worked for me.

Recently, on my new 64-bit home development machine, I fired up Visual Studio 2008 for the first time in a while and decided to start cranking out C# solutions to the Project Euler questions. Since I have already completed 14 questions about a year ago, I was able to code a solution to Question #1 very quickly. I decided to debug the solution and ... wham. I received the following error -

To resolve this issue, you will need your Visual Studio 2008 installation disk. On this disk, you will find the following path -

Inside this folder should be an executable called "rdbgsetup.exe". Run this EXE, open up Visual Studio and you will now be able to remotely debug your projects.

For the last 5 days, I have been encountering an error when trying to automate the creation of an Excel document through a scheduled SQL Server job. The error I was receiving was -

Exception from HRESULT: 0x800A03EC

Let's take a step back. The same code I had written worked on my development machine, worked on other target servers while scheduled as SQL jobs, but the code would not work on the following target server -

• Windows Server 2008 Standard
• 64-bit platform
• SQL Server 2005
• Excel/Office 2007 Professional

After adding some StackTrace code to my program, I was able to determine that the EXE was failing on the Microsoft.Office.Interop.Excel.WorkbookClass.SaveAs line. After trying multiple iterations of the SaveAs command (a quick Google search provided some potential solutions), I continued to get the same 0x800A03EC error code. I went down the road of thinking it was a problem with my 32-bit development environment and had our Sysadmin build me a 64-bit virtual machine for me to compile my application; however, this also yielded the same error. I made sure that the Excel assemblies on the development environment and the target machine were the same version. On the target server, I went to dcomcnfg, selected the Microsoft Excel Application entry and made sure it was using the "interactive user" and still no luck. I made sure that, for testing only, all the SQL services ran under my domain admin account to account for SQL security differences and still nothing.

At this point I decided that I was spinning my wheels and I would call Microsoft and use one of my MSDN support cases.

After speaking to several departments, I finally reached the Office department who tried to help. After explaining my issue quite a few times over and over, I finally got the response I had dreaded - it can't be done that way. Ugh. I had feared I would get this response after reading that using Open XML to create Office documents was the recommended approach and that using the Office COM references was no longer supported (if it ever was) and Windows 2008 has additional security that prevents the old approach from working properly. Well, I guess that explains why it wasn't working.

So where do I go from here? Even though Microsoft support couldn't provide me with sample code or a link to some code, I was able to find this knowledge base article detailing how to to create Excel files using Open XML. Hopefully, this approach will work on my target server environment.

Recently, a client wondered how they could add an external document to a document library that existed on their Intranet. The problem with just saving their document and uploading it to the Intranet is a matter of document "freshness" as changes are made by the document owner. Therefore, creating an external link to that document is a much better solution. However, adding a link to a document library would seem difficult on its face.

To get around this issue, I took the following steps -

1. Create a TXT file.
2. Open the TXT file and add the following HTML -

<html>
<head>
<title>External Link</title>
<script type="text/javascript">
window.self.location.replace('http://www.somesite.com');
</script>
</head>
<body>
</body>
</html>

3. Save the file as a HTML file.
4. Upload to your Document Library.

You now have a working JavaScript redirection to the external document in your document library. Also, you can click the Back Button in your browser and you will return back to your Document Library.

Recently, I decided to go through my work computer's event log to see if I was racking up any errors and found one error repeated quite frequently -

Now, I have Microsoft's SQL Server 2005 installed on my work machine for development purposes and the error seems to be directly related to the Reporting Services functionality. After looking at the help for this error in the Help files, Microsoft's web site and even a few search engine searches, I couldn't find the full answer anywhere. However, I finally fixed the error and here's how to do it.
Reporting Services Configuration Manager

1. Open up the "Reporting Services Configuration Manager" by going to Start -> Programs ->Microsoft SQL Server 2005 -> Configuration Tools -> Reporting Services Configuration.
2. On the left hand side, click on "Database Setup". (there should be a red "x" to the left of Database Setup.
3. Choose the appropriate Server Name.
4. For the Database Name, click "New" and do not use the default name "ReportServer" since it's possible a .MDF file was already created with this name. I used "ReportServer2".
5. Make sure to choose the "Credentials Type" and enter the account information for a user who has create database permissions.
6. Click "Upgrade". Make sure you get all green check marks (even a warning message means the process probably didn't complete properly).
7. Click "Apply" at the bottom.

You should now be good to go and no longer receive this error in your Event Log.

The following code will help you create a very basic Word 2003 document using VB.Net. In addition to the code below, you will need to make sure that Office is installed on the host running the application for the document to be created.

The following contains code on "How to Create an Excel 2003 Workbook Using VB.Net". Remember, you will need to add the "Import Microsoft.Office.Interop" reference at the top of your code. In addition, you will need sufficient rights to create files in your desired save location as well as Office installed on the machine hosting the application.

Sometimes when you are self-taught, you may know how to do something, but you do it the hard way. Therefore, sometimes even the smallest little feature you didn't know about can really make your day and improve your coding efficiency. Today, I stumbled over the addition of conditional breakpoints in Visual Studio 2005. Now, I'm sure any serious coder probably already stumbled over this feature, but I had not until today. A conditional breakpoint is exactly what it sounds like - it is a breakpoint that will be triggered during the debugging process only when a condition you specify is met.

Using Visual Studio 2005, you can set a conditional breakpoint by placing a breakpoint on a desired line much like you have in the past (click the gray area to the left of the desired line). A red dot will appear representing the breakpoint. When a user right clicks on the breakpoint, you will be presented with a list of options that include:

• Delete Breakpoint
• Disable Breakpoint
• Location
• Condition
• Hit Count
• Filter
• When Hit

Anyone who used Visual Studio 2003 as their primary development environment would be surprised to see all these new options in the 2005 version. If you choose the "Condition" option, you will be presented with a dialog box that asks you to input a condition and to choose whether the condition "Is True" or "Has Changed".

Conditional breakpoints are extremely important for debugging problems that exist in WHILE loops, FOR ... NEXT loops, etc. especially when dealing with extremely large loops. Say you have a single record bombing out in a huge loop and you are being emailed the CATCH exception. Instead of setting a breakpoint and continually hitting F5 to eventually get to the record that your application is bombing out on, you can now just set a conditional breakpoint, run your application and have the debugger stop the process right as you get to the problem record.

I'm excited to have "discovered" (yeah, I know, I'm late to the dance on this one) this feature as it should drastically improve my debugging and shorten troubleshooting time. Hopefully, if you weren't already aware of this feature, you are now and will help you in your .Net development.

While extremely unrecommended, sometimes you just want to fix a problem quickly and without jumping through a ton of hoops using the SharePoint SDK and writing a small C# program. I recently encountered this when I needed to delete a Folder from a whole bunch of Document Libraries across hundreds of sites. Making sure that I checked to see if the folder was there first, calling the right Web, calling the right List, getting the right Folder GUID, etc. all seemed like a lot of work for a simple SQL statement so I cheated.

Folders all stored in the AllUserData table with a tp_ContentType = 'Folder'. I was able to write a simple UPDATE statement like the following to delete the unwanted folder across the sites I wanted -

Quick and very dirty. Not recommended, kids don't try this at home.

Today, at work, I was working on creating an application that would perform validated, bulk updates to our accounting system software (Deltek Vision). So, I create a very simple Windows Form, create a real quick GUI, write all the necessary validation and then started writing the stored procedures needed to perform each of the functions. I had already written the SQL syntax as before this application I was manually changing the variables to fit the needs of our business units. However, as I was trying to "generalize" the statements to allow for different types of queries, I started to run into a SQL problem. I was attempting to use dynamic cursors that were being fed by dynamic SQL statements. Yikes.

In English, I had created two cursors - one to read through all the "target" projects and one for all the "source" information. I also gave the user the ability to specify whether or not the target was "equal to", "starts with" or "ends with" a certain criteria. This causes a problem since if you know general cursor syntax you know that a cursor is fed with a select statement as such:

Now, by giving users the ability to dynamically change the entire WHERE clause (including the operator), you suddenly run into a syntax issue because you can't just store the entire clause in a varchar variable and then have it EXEC SQL (@stmt) because of later references to the cursor. Since that eliminates one major way of preparing dynamic SQL statements, I developed a very dirty solution that revolved around IF statements -

Pretty dirty right?

Most of the time when I post code here, it's generally the non-dirty version, but I really couldn't find a non-dirty version to this problem and would really like to see if someoone has any ideas on a better, cleaner solution. It seems that all of the sample code I saw online when searching "dynamic cursors" only made table names or WHERE criteria (not the operator) dynamic and therefore fails to appropriately address my issue. I got away with this solution since the problem was simplistic, but what about if I had to deal with 1000 conditions - I wouldn't want to write 1000 IF statements.

Thoughts?

P.S. - As I read through the SQL Books Online, it seems that the PREPARE statement might be able to solve this problem, but I don't have much experience with PREPARE.