I didn't say that. You did say that. But again: whyI had to work with T-SQL which I would call an abonimation. Each product has it's irks, but I rather deal with Oracle's NULL string handling than with the half baked SP language from Sybase. BTW: Did they finally manage to have a decent transaction model, or are dirty reads still an option?
Sybase? I am not in love with Sybase. I only respect
I didn't say that.You said:
That's the point - Oracle's spaghetti code, millions of lines of code based on screwed up definition of NULL.As you said yourself, spaghetti code is a pejorative term used to describe code that is poorly structured and thus hard to maintain. So presumably the reason why the null semantics of CHAR and VARCHAR2 values can not now be altered is because of the poor structure of Oracle's code. That's what I'm disagreeing with.
language from Sybase.
standard, and for all SQL database implementors.
All vendor implementation specific problems arise
from the conceptual problems.
Preference between Oracle and MS treatment of NULL is
like to choose between be hung or be shot.
<quote>Dirty reads were never an option in Sybase. Where have you read this?
Please, avoid the never-ending confrontationAfter working with it, that's my opinion on that topic.
Oracle-Sybase. This is the least I wanted. Also, this
is not the right place for that.
You talk about "abonimation"? Hmm...
> ..., but I rather deal with Oracle's NULL stringComing from you, this could still be a compliment.
handling than with the half baked SPlanguage from Sybase.
You are welcome. But it doesn't mean you are very
> BTW: Did they finally manage to have a decentSo they've finally introduced MVCC or the like? Writers don't block readers anymore? What about the spaghetti code that relied on this?
transaction model, or are dirty reads still anoption?
Dirty reads were never an option in Sybase. Where
have you read this? There were some problems with
locking that was fixed a long time ago.