Late last year I used the DevExpress controls for a small task after they were recommended by a friend. Very similar to the native ASP.Net controls in Visual Studio 2008, just more powerful and better looking too. I had a grid control on a web page that needed some changes, swapped out for the DE grid in just a few minutes, no problems. In particular it handles editing of the row very nicely, and it ‘gets’ the concept of having a combo box of possible values in a cell with very little effort to make it all work.

Based on that I decided to request a license (a minor perk) and start to use it on a more regular basis. A couple weeks later I decided to replace another grid as part of some routine work and while it displayed data just fine, the edit failed. No error message, just nothing happening when I clicked on edit.

Looked at first effort, compared to new, didn’t see any differences. Looked again. Tweaked a few settings, still nothing. Can’t be the controls because the other code ran fine on the same machine. Looked some more. Sound familiar in our business? Finally gave up and called it a day. Next morning I started by swapping back in the original grid, wanting to make sure it wasn’t a SQL error, bad permissions, something like that. All worked fine. Swapped the grid back, resumed comparing and this time – being rested – noticed that the first grid did had an insert defined, the new one did not. Couldn’t see another difference, so created the insert proc and configured it, clicked Insert and got an error that the ‘primary key was not found’? Huh? A clue?

You’ll enjoy this, turns out that the column name of the primary key is case sensitive in code. Not a case sensitive database or column, just the column name in code. Fixed the case to match the table, worked fine. Changed back, failed. Changed back, worked. Verified this with DE support, it’s there to make things .Net related work. Of course the end result is that if your developers use the DE grid you can have some fun with them by changing the case of a column name!

It’s not a huge problem, most of us rarely do something as trivial as fix a column name, other than cases of changing “EMAIL_ADDRESS” to “Email_Address”. My complaint was the lack of error message on the edit error, and even that is a small case as I imagine most people would have defined an insert that would have revealed the problem.

That aside, so far I like the tools, nice productivity gains for a lot of the routine data edit type stuff I have to put together.