Wow that must suck - the IComparable code must take a long time to write.
I am the laziest programmer you will ever see - I can assure you that.
Here's another funny story. I was working for this client where they had
this strange request of running multiple versions of their application in
production. This was a combination of an app server and a client and a
database.
So they came up with this solution --
..NET framework can run multiple versions side by side. Let us leverage that.
The client over remoting will always use the right versions, however it
connects on a different userid - therefore we can compile stored procedures
that are always backward compatible with atleast one version (assuming you
have at most two versions in production), and we could then distinguish the
right stored procedure to call using the exact user id used to connect to
the d/b and hence the datalayer would have to call <<ownerid>>.StoredProc
instead of storedproc. When a new release comes, everything will play 69 and
previous release becomes new release and so on so forth. If we need to
support more than 2 releases in production we simply need to use more than
one owner id .. THATS IT !! SIMPLE .NET ROCKS !!.
I was sitting there and I said this --
"Why don't you just run a brand new app server connecting to a seperate
database?"
And everyone in the meeting room was like "Yeah or we could do that" !!
HAHAAHAHA !!
Anyway, I think the solution I proposed to this dude for comparing two
datasets works - I think it should. But maybe it might need a little bit
tweaking for the rowstates
- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik