Category Archives: Programming

Programming

GetType() Vs. Is

I wrote two functions and disassembled them using Reflector:

.method private hidebysig static bool CompareWithIs(class ConsoleApplication1.A x) cil managed
{
.maxstack 2
.locals init ([0] bool flag)
L_0000: nop
L_0001: ldarg.0
L_0002: isinst ConsoleApplication1.B
L_0007: ldnull
L_0008: cgt.un
L_000a: stloc.0
L_000b: br.s L_000d
L_000d: ldloc.0
L_000e: ret
}
private static bool CompareWithIs(A x)
{
return (x is B);
}

Programming

Debugging XAML and Prism

The biggest frustration in my Silverlight development is debugging errors in my XAML code.  Since our app uses Prism, there are often three different .xaml files involved in any one change to the app: App.xaml for global styles, Shell.xaml for the main layout and a .xaml file for whatever view I’m working on.  If something goes wrong, knowing what file it’s in is half the battle.

Unfortunately, the errors that Silverlight throws when you have malformed XAML can be pretty obtuse.  Through trial, error and a little intuition I’ve figured out that there are some patterns:

  • If nothing at all renders, the problem is likely in App.xaml.  That gets loaded first, and if something goes wrong then you get bupkus.  Check for syntax errors in App.xaml.
  • If the only thing that renders is the spinny loady thing (I actually don’t know if this is a Silverlight default or a StockTraderRI thing) then I think that usually means the problem is in Shell.xaml.  App.xaml has loaded at this point, but something is keeping the rest of it from going.  Often this can happen if you’re referencing something in App.xaml that’s syntactically valid but semantically nonsense.  Check especially for mis-spelled values inside Setter tags, or badly structured ContentTemplates. Continue reading Debugging XAML and Prism →

Programming, SQL Server

Importing CSV Data into SQL Server

On a fairly regular basis at work I have to take .csv files with data from a customer’s database and import them into my SQL Server instance. This should be a simple operation, but the design of the native SQL Server Data Import tool makes it much, much more complicated than it needs to be. The biggest pain point by far is having to specify the data types of every single column in the data source by hand. Not only does it assume that everything is a string, forcing me to go through and figure out which types are a date, an int, a float or whatever else I have in the database, but by default changing a column’s type to a decimal uses decimal(18,0), truncating all my floating point values.

It always seemed a bit absurd that I should have to manually specify the types of all my data since I was importing into a database where the data types of the columns are explicitly specified. Once the import tool knew what table I was importing into, shouldn’t it be able to figure out the types for me?

So I wrote a Python script to import data for me. It uses the pymssql module to connect to the database, and the main insert function requires only three arguments: a connection to a database, the name of the table to import into, and an object with a function to return the names of the columns and then be able to iterate over the data. Conveniently, I also wrote a CSVFile class that wraps around a .csv file and provides just that functionality. Continue reading Importing CSV Data into SQL Server →