Blog Posts By Denis

Trying to be a “Good Windows User”, I installed the last few Windows system updates. Unfortunately, I also need to be a “Good .Net Programmer”, and one of the recent security updates made it so that my local machine could not serve up ASP.NET pages anymore. I could surf to HTML pages on “localhost”, but trying to load up any of my local ASP.NET pages caused the WWW Publishing service to stop. The culprit was a conflict with COM+. I tracked it down to an error in the Application Event Log with the following message :

“The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. Error in f:\xpsp3\com\com1x\src\comsvcs\package\cpackage.cpp(1184), hr = 80070002: InitEventCollector failed”

After trying a few solutions that didn’t work, I found out about the Windows update problem, and an approach to fix it here :
http://support.microsoft.com/kb/315296

I was able to repair my COM+ install using the method from that page. My machine is now telling me (again) that I have an important Windows system update to install, but I think I will hold off for a bit…I have actual work to do.

The crew at 4 Guys From Rolla have come through for me again (as they frequently do in matters of ASP, .NET and SQL). In building a new webservice, I wanted to be able to pass in a comma-delimited list of ID's to a SQL stored procedure. Unfortunately, there isn't a SQL datatype for something like "comma delimited list". I could have taken the "easy" way out and built the SQL query dynamically in C# instead of calling a stored procedure, but then I would have been mad at myself for breaking the rule that we agreed on that all the webservices would strictly call stored procedures. I figured I'd have to use SQL to parse a passed in string into ID's, and build the SQL query from there. However, this seemed like something someone else probably would have done in the past. I found a few techniques online but this one seemed the cleanest and best-implemented. You basically pass in a big varchar string of id's into the stored procedure and then call a SQL User Defined Function called "Split" which returns a table of the ID's which you can join to. It's simpler than it sounds...instead of having something like

SELECT *
FROM table
WHERE id in (--lots of convoluted code to parse out the ids--)

you just call

SELECT *
FROM table
WHERE id in ( SELECT convert(int,Value) FROM dbo.Split(@list_string,',') )

The complete code for the function and examples of how to use it are listed in the article. Thanks to "4 Guys" for saving me a couple hours and some headaches with this nifty technique!

Call me old school, but I like all my projects in Visual Studio .NET to be standard class library projects rather than "web" projects. I am sure the Web Projects wizard is very useful for creating quick applications, but as with any wizard, it decides some things for you during set-up that might be hard to edit later. So, what happens if you inherit a solution file that is a Web project, and you have no idea how the virtual directories and references are set up? Unfortunately, you cannot open this project in Visual Studio to edit those settings! What I forgot today was this : "The Project files is just a text file, that you can edit in notepad". Once I figured that out, I was able to change "ProjectType" attribute from "Web" to "Local". Magically, I could open the project, update my references and compile about 2 minutes later.

I have a love-hate relationship with the "SetLocale" function in ASP. A recent challenge was to build several international versions of a website. We wanted it have one code-base with different settings and translation files. ASP's "SetLocale" function was invaluable in getting this working correctly, but here are a few things you may want to pay attention to in a similar situation, especially in regard to setting currency display :

* Currently there is no "Euros" locale. With a Windows XP 2003 server, the only locale setting that shows Euro format for currency is "es-es" (which is Spain). So, if you want your German site to show currency as Euros using ASP's "FormatCurrency" function, you have to set the locale to Spain. It works, but doesn't seem ideal. Perhaps have a setting for "Currency-Locale" which you set before displaying any currency on your site, and then switch back to the original locale once you display?

* Notice above I said, "Windows XP 2003" as the OS...If you happen to have an older OS (in our case, one of our TEST servers is an older OS), your road is more difficult...you just have to trust that Euros will work on a properly updated server...either that or the headaches of trying to write your own CurrencyFormat function.

As long as you are aware of the above issues, you should be all set. A great summary I found for this issue is at this site.