Ok, after spending another 1/2 day battling with the oracle tools for devstudio, i took the plunge and reflected the whole Oracle Data access component. I’m not sure I should be publicly admitting to reverse engineering Larry’s baby but if its the only way I can find out what broken, so be it. They should learn to write working code.
So I dig out reflector and run the ODP.Net assemblies through one of the reflector add-ins that brings it back to something more readable.
On inspection it seems that they’re mixing the domain values for db nulls. the OracleString performs a conversion when the column is null and actual returns the string “null”! Poor? Well I think so.
So, the next step is to look through the designer code that the ODT spits out when you drag a stored procedure onto a data set design surface. It appears to work ok, until you try using any procedure that involves varcar2 out parameters. Then it chokes. Nice.
The problem is it looks like their generated null checks aren’t working correctly. They’re testing the returned objects against NULL, and then if the object isn’t null they’re comparing the objects Value with System:DBNull. This obviously wont work since an they always return an Oracle type and the value throws an exception if the Oracle type is null. Not only that, but their implicit casting in the generated code is broken too, although that seems to be a symptom of their checks for null failing and going on the read the Value in order to cast it to a real .Net type.
The fixes are pretty simple, but it does involve editing the Table Adapters designer .CS file and fixing their ropey code.
I encountered these problems a couple of years ago, and swore never to trust them again, but heh, this is 3 years later, surely they’ve fixed the casting bugs?
Apparently not.
So, if you have the choice stick with SQLServer. For all MS’s flaws they seem to emit bug free code, and they do fix stuff.
<rant over/>