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 F***ING
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. (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