Manipulating Xml with C#

I'm pretty fond of the XDocument class. XDocument lets you have your way with XML without requiring convoluted syntax, especially when used in conjunction with lambda expressions. Here's an example to change the value of an attribute on nodes that were found through a search criterion.

XDocument xDoc = XDocument.Load(

    new StringReader(

        @"<Customers><Customer ID=""99"" Description=""Just another customer""></Customer></Customers>"));

xDoc.Descendants("Customer").ToList().

    ForEach

    (e =>

        {

            if (e.Attribute("ID").Value == "99")

            { e.Attribute("Description").Value = "Our best customer"; }

        }

    );

Hiding ASP.NET Configuration Files from VSS

All I wanted to do was to keep a few ASP.NET web site files from being versioned by Visual Sourcesafe.  Seemed like a reasonable request.  I'm talking about deployment specific configuration files with things like server names in them that are referenced in web.config using the configSource attribute.  This approach is necessary for real world scenarios, where, for instance, a production server would not know what to do with the name of a database which is located only on my dev box.  Unfortunately neither Visual Studio (current version 2008) nor VSS knows how to ignore any ASP.NET files.  

I wonder what does everyone else does? I've met few ASP.NET developers who actually know about the configSource attribute. And I suspect that the few that do probably struggle originally as I have with an occasional mishap and then turn to batch scripts like as I have done for many months now.

There must be a better way, I mumbled to myself this morning. So a-Googlin' I went. Through a quick search,  I've encountered several blog posts suggesting a hack on the vssscc file for the solution. Suppposedly you can add a line like "EXCLUDED_FILE0" = "filename" and reset the "NUMBER_OF_EXCLUDED_FILES" line. There's only one catch; it doesn't work.  There went 30 minutes down the drain.

After more extensive searching, I was able to find an awkward but workable solution, from a post on a slightly different topic, which is to set the machine specific files as "hidden" in Windows. Never used that feature of Windows before!  Never had a need to.

There you are. Easy, right.  Yeah, it's easy all right, once you know.  Hard if you don't know. I can't decide: Is it surprising that  productivity insights are about the hardest thing in software development to Google for, or is really not surprising at all?  After all, internet "knowledge" seems to be mostly the blind-leading-the-blind.

It took me months to buckle-down and hunt for a solution to this annoying problem. I'm really glad I finally got around to it. I certainly hope, however, that in the future my futility-o-meter becomes more sensitive and I don't wait as long when I run into productivity snags.

Sorry. We Get the Support Documentation We Deserve

We programmers love to mumble to ourselves in abject silence about how poorly a commercial framework, api, server app, etc is documented. Though such complaints might be understandable, I suspect that the lack of effective documentation is many instances at least partly a function of apathy on the part of the user base.

Recently, I ran into perhaps the vauguest and cryptic Oracle error messages of all time: "ORA-01461 can bind a LONG value only for insert into a LONG column."

Huh? LONG? LONG is a defunct data type. Hey Oracle, what I really need to know is which column? And which table? And what exactly is meant by a "LONG value?" It's just a string characters.

Eventually I figured out that the offending insert statement referred to a column that was varchar2(4000 characters). But my string only had 2020 characters. So I should be good. Right?

Turns out Oracle has a built-in global limitation of 4000 bytes, not characters, for a varchar2. See http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/datatype.htm#CNCPT01. Even if you specify 4000 characters, the 4000 byte limit overrides. Depending on the encoding a character can be and usually is greater than one byte. Characters are typically 2 bytes. So my 2020-character string actually occupies 4040 bytes. Thus, my insert was over the global limit.

But why does the error message use the term LONG? The LONG data type can be up to 2 gigabytes. Evidently, this error message dates back to yesteryear when the only way to upload a character string longer than 4000 bytes to a table was to use a LONG column. Today, you can use a bunch of different LOB data types, instead of LONG.

Here's what really burns me: Googling "ORA-01461" provided no answers. Hmmm. What's up with that, my fellow Oracle programmers? Okay, so Oracle is not connecting the error message with the likely context in which you would see error message. Yes, that sucks. But what about our responsibilities? I haven't run across anyone on the interwebs complaining about how utterly lame and useless this error message is. If we don't complain with specificity and articulation, don't expect old-line software vendors such as Oracle to give a hoot.

Variables in Sql Developer

Ever find yourself having to remember how to to use variables in Oracle's handy tool Sql Developer? Me, I can never remember. That's why this post is here.

There are two types of variables in the Oracle world: substitution variables and bind variables. It's important to remember that you can't use substitution variables in Sql Developer, but you can use bind variables. The syntax for bind variables is the following:

variable custno number

exec : custno := 99

Select * from customer where customerId = : custno;

Now I'll remember.

.Net Code Converters

Once in a while I find a useful code sample written in VB.Net. Today I needed some code that essentially does the work of OracleCommandBuilder.DeriveParameters, but with some modifications. I found a code sample for just such a class, posted by someone named David Browne at http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-ado-net/116/Returning-Stored-Procedure-Parameters. Unfortunately, Mr. Browne's code is in VB.Net, whereas I'm in the middle of writing an app in my preferred language, C#.

The best code converter I've found thus far is from Telerik at http://converter.telerik.com. What's key about this converter is that it gives you very helpful translation error reporting for the inevitable copy-and-paste glitches that accompany any sizeable snippet gleaned from the web, such as inappropriate link breaks.

Edit and Continue vs. Lambda Expressions

Microsoft giveth and Microsoft taketh away. One of the amazing gifts of .Net 3.5 is lambda expressions. Once you start using them, it's hard to stop. Unfortunately, lambda expressions are not compatible with another innovation: Visual Studio's Edit and Continue (or EnC). If you try to edit code with lambda expression while debugging in VS you get the following:

"Modifying a 'method' which contains a lambda expression will prevent the debug session from continuing while Edit and Continue is enabled."

According to this post, EnC is also incompatible with anonymous methods, a limitation present since .Net 2.

Data Dude Has Trouble Diffing Views, Stored Procedures, and Functions

Data Dude's schema compare feature is a technical wonderment . . . when it works. It seems to be fine when comparing databases to each other. Unfortunately, when comparing a data dude "project" to a database created independently from Data Dude, Data Dude seems think that there is extra whitespace in its cached copy of the ddl for the database's view, function and stored procedure ddl. What's going on here? It turns out that Data Dude is very picky about what is considers properly written ddl definitions. Data Dude wants you to allow it to write all the ddl to the database! Thus if you have created your database objects in SQL Server Management Studio you'll have to resync going from the Data Dude project back to the database after importing the schema from the database--a full round trip. You should be careful about backing up, as always.

It's a shame such a great tool has such a lame bug.

Note: Data Dude is the nickname for the Microsoft project formally known as Visual Studio Team System 2008 Database Edition.