Catch Those Pesky WPF Data Binding Errors!

After months of changes to a WPF app, today I noticed that the Visual Studio output windows was frought with warnings about "System.Windows.Data Error" when debugging the application.

Aside from a poorly performing app, on principal I dispise any uncaught problems in an application, wanrings, errors or otherwise. Leaving it up to the runtime to deal with misbehaving code is a sign of a lazy developer.

After looking into it more deeply, I remembered an off-handed article I read some time back about how WPF has implemented XAML data binding errors as warnings rather than hard exceptions. While there's no way to change this aspect of the runtime that I know of, there are a few helpful hints here: http://beacosta.com/blog/?p=52

A note to developers: fewer exceptions (caught or uncaught) in your code means a faster performing application...period. The less the runtime has to babysit what your app is doing, the more time your application has to do what it's supposed to do.

Serves me right for disregarding the optup window for so long.

SQL Server 2005 Database Diagrams

Trying to Make Sense of the Mess

So database diagrams are supposed to help you ensure that proper indexing and referential integrity is enforced where it should be in your database. Oh yeah, and it should help to visualize the relationships in your database.

On the first account, it does, and I definately see its usefulness when implemented successfully. On the second, it only helps visualize the most trivial of databases. Anything beyond 10 related tables and you can forget about *any* single useful view of your database; databases are not meant to be visualized from a 2D surface.

However, there are some caveats to database diagrams.

Copying the Diagram

For one, copying the diagram to another database is, er um, not as straight forward as one would expect.

If you want to copy the *visual* depiction as a graphic, say for print-out, all you have to do is open the diagram up, wait for it to load completely, then right-click the surface and select the 'Copy to Clipboard' option. But again, this is really only useful for small database diagrams, unless you like the idea of single-handedly killing the rainforest with all those reams of paper you intend to print the diagram out on...just so that you have a nice, pretty picture up on your wall of the chaos that is your enterprise database schema.

If you want to transfer the diagram to another database though, you have some options:

• Restore the database from a backup of the source database where the diagram is in-tact.
  
  CON: This doesn't take into account differences in data between the source and destination databases.
  
• Script the diagram out to T-SQL from within the source database, then execute it on the destination database.
  
  PRO: While this option isn't available from Management Studio as you would expect it to be, considering that you can do this with just about every other database artifact, there's already a solution for how to do this on codeproject.
  
  CON: This method requires you to add artifacts to your source database, which not all of us have the luxury of doing (e.g. a closed vendor product, production audit processes, etc.)

I ended up using the second approach, since export of a database diagram into the SVN repository is explainable in a SQL audit. However, I wish Microsoft had implemented this in Management Studio to begin with. It was probably something that didn't make the final cut of the tool set before RTM.

A real shame it didn't though.

ODBC on x64 (MDAC x86)

Note to self:

When developing with old components and receiving wierd messages, try compiling for x86 and running. Chances are, if the code can't see a GAC'd dll, it's because you're running in x64 and the 'missing' component is compiled for x86.

This occurred when attempting to use the Microsoft Text Driver from an x64 machine. The ODBC Data Sources dialog doesn't show all the (x86) drivers installed...that is unless you run it from an x86 command prompt. So I thought I had to install MDAC 2.8, but even after doing that, the code was still choking.

I also ran into this while working on a project that required the SQL Server Replication components, which are also compiled for x86. Fortunately, my brain was switched on today.

Links from SQL Server 2008 Analysis Services Training in Boston

Went in to the city Mon-Wed for SSAS training and Compuworks. Highly recommend them.

Links from conversations in the training will be posted tomorrow (2009-12-10 Thu) when I get back in to my desk at Gordon.

Linq to SQL and Temporary Tables in Stored Prodecures

If you have problems when dragging a stored procedure from the server explorer to your Linq-to-SQL designer surface, try adding the following T-SQL code to the beginning of your stored procedure body:

IF 1=0 BEGIN

SET FMTONLY OFF

END