I think the problem is that nobody wants to say "Oh yeah, solid as a rock!"
and then have someone die as a result of a database error. However, I have
personally witnessed unrepeatable database errors in both MSSQL and Oracle.
Those databases both have marketing departments widely touting them as
"mission critical" databases. I've had MSSQL databases fill the log tables
with crap to the point where the whole database crashes because Microsoft
decided it was time for a dll change -- and they didn't tell anyone "Hey, be
sure to un-check the 'Let Microsoft ruin your life' checkbox". (that was an
emergency personnel tracking database on an offshore oil rig). I've managed
the development of an entire application based on Y2K compliant Oracle only
to find out that it's only Y2K compliant if you enclose EVERY SINGLE READ
AND WRITE in a goofy-ass "FORMAT" statement. Although, if you don't use the
FORMAT statement, it will still accept four digit year entries without
barking, and it will also display four digit years based on the two digit
year it actually stores (so I guess if you never know the difference, what
does it matter, right?). By the way, even if you use the Format statement,
Oracle still craps out after 2035 (it was a rather carefully worded Y2K
compliance statement that accompanied that application). (that application
was a safety statistics tracking database). Soooo, for my part, I now put
my faith in a database whose proponents do not face financial ruin if they
tell you the truth. I much prefer a "Not yet implemented" message from the
database, or a "this is still a little wonky" message from the developer, I
much prefer that rather than the confident assurances you receive from
Microsoft and Oracle. Especially when you pass on those confident
assurances to your client and wind up looking like an ass.
Sorry to explode. I feel better...
David Boerwinkle