This content has been marked as final. Show 385 replies
DIRTY READS WERE NEVER AN OPTION IN SYBASE. THEMy bad, I should have written it like this: "Are dirty reads still a method for developers to bypass some of the limitations in Sybase if they want to avoid certain (dead)lock situations?" Since you did confirm that readers block writers, I'd say that's the case, which somehow contradicts your argument about technical merit. EOD for me.
ISOLATION LEVEL 0 WERE.
but dirty reads and the isolation level 0 are not
Albert, I wasn't referring to the quotation marks around the words "touched" and "non-touched", I was referring to the definitions of NULL you Re: Treatment of zero-length strings as NULLs? from Wikipedia. I couldn't see the relevance of them to your argument that Oracle's treatment of empty strings is in violation of some alleged industry standard, if that is one of your arguments.
Are you arguing that Oracle's treatment of empty strings is in violation of some alleged industry standard?
Were those definitions of NULL intended to show that Oracle has it wrong?
Possibly you meant to show that the standard definition of a null value differs from your requirement for a known empty value, and therefore demonstrates that Oracle is missing something. Possibly you meant something else.
I can perfectly understand the benefit of being able to specify "no mobile phone number" as a known fact distinct from "mobile phone number unknown or not required". My own view is that for a minor benefit you get double the complexity because you have two kinds of empty and you need twice as many constraints. What puzzles me is why you think Oracle and anyone who disagrees with you is fundamentally wrong and an idiot.
1. The way you ask, and most importantly, what you ask, convinced me that you had never worked with ASE. You might read something about the server here and there, maybe even issue some queries, but you've never worked with Sybase. Am I right?
DIRTY READS WERE NEVER AN OPTION IN SYBASE. THEMy bad, I should have written it like this: "Are
ISOLATION LEVEL 0 WERE.
but dirty reads and the isolation level 0 are not
dirty reads still a method for developers to bypass
some of the limitations in Sybase if they want to
avoid certain (dead)lock situations?" Since you did
confirm that readers block writers, I'd say that's
the case, which somehow contradicts your argument
about technical merit. EOD for me.
2. I confirmed that readers block writers? Forever? And you believed that? No, it was just my New Year's Gift to you. I hope, you enjoyed it. I could also have written it as: "No, now brains block jerks forever", but was afraid you'd never enjoy it.
For additional fighting go to the forums.sybase.com and say there what you have. This is not the place for it.
I didn't forget I owed you the answer. But today is Saturday and, as you know, right now begins Saturday Night Fever. Tomorrow is Silvester Night Fever. So, until Tuesday.
A Happy New Year to you and all members of this interesting forum, specially to those who took part in this thread.
I know, I wrote EOD, but one more answer in the old year seems to be fine.
1. The way you ask, and most importantly, what youUnfortunately, I had the misfortune of developing with T-SQL.
ask, convinced me that you had never worked with ASE.
You might read something about the server here andNo, you are not. Other questions in T-SQL could be: Did they introduce array structures after 12.5? Is the text datatype for variables finally supported?
there, maybe even issue some queries, but you've
never worked with Sybase. Am I right?
2. I confirmed that readers block writers? Forever?As long as transaction lasts, I'd say.
And you believed that? No, it was just my New Year'sI'm afraid I can't follow you. Did Sybase finally change it's transaction model, or not? If not, then what has that got to do with strong wording?
Gift to you. I hope, you enjoyed it. I could also
have written it as: "No, now brains block jerks
forever", but was afraid you'd never enjoy it.
For additional fighting go to the forums.sybase.comAgreed. So do you have any questions on Oracle topics, or do you want to keep complaining about the differences between the Oracle DBMS and other products?
and say there what you have. This is not the place
Almost forgot: Here's a Re: New Year Wishes the PL/SQL way. ;-)
Sorry, that should read ?extent? not ?extend?
> Keep in mind, however, that this> Maybe, but only to the extend that it ran.
"primitive" ASE 22.214.171.124 was good enough to runmost
of Wall Street during the 90's.
I accept the extend: IT RAN. Today,
It only ran as well as it did, to say. Whereas, is possible it could have run as well as it could have. If you follow. If accepting that this market is leader, then it depends the length of margin which may be better without limitation of Sybase.
Now, I must go sleeping and cannot discuss.Yes I see you appologise for this already, however I am made this comment in reply to "you understand nothing" in humour only.
I've already done this. Once again:
(*) We should all praise our lords that the SQL3
standard initial draft didn't go ahead allowing
multiple user defined NULL types.
User defined NULL types? You really understandnothing. User defined NULL types would
be the negation of NULL, ~NULL or (NOT)NULL that isagain NULL.
I'm so sorry. I've read your double-quoted text
wrong. Too tired. I do apologize.
You have not acknowledged the main point of my rebuttal that SQL NULL is not (as you claimed) a fundamental part of either set theory, or relational algebra.
The SQL NULL is not the Empty Set.
The SQL NULL is not part of relational algebra. SQL NULL requires 3VL and as relational algrebra requires the Law of Excluded Middle, 3VL is out of the question, so you will not find a SQL NULL in relational algebra (or relational calculus.)
SQL NULL is a SQL adhoc-ism. It's a mistake, and it follows that all implementations are equally mistaken. As soon as you accept 3VL you find you need 4VL (as you have) and it follows that to complete you must consider all possible NULL contexts (there are about 23 as I said earlier)
Should you (or those writing the ISO SQL rules) decide that this NULL concept can be explored to it's logically correct conclusion then personally I believe the level of complexity foisted upon us as end users of database products does not bear out in the fruits of productivity.
More so, if you accept to use one product as a professional, you must understand the quirks and live with them.
Specifically, to try to rationalise one vendor mistake over another is a waste of time.
Well, you can take as many left and right turns in your discussion and dissection of the statement but if you are NOT denying that dirty reads happen (no matter in which isolation level) then your statement that "dirty reads were never and option in sybase" is not correct. Maybe you mean that they were never an option but were rather a necessity in sybase?
No, no, you were, in fact, discussing the isolation level 0. The link you gave "Dirty reads" is a
subtitle of "Choosing an isolation level" parent title.
And hence means you agree dirty reads exist (in which isolation level they exist and in which they do not, is not the question here). The question is simply -
Without the isolation level 0 dirty reads don't exist.
"Do they or do they not exist in that product?"
Again, I was just quoting the link where dirty reads is the topic of discussion. The link talks about dirty reads. It does NOT matter it is subtitle of something or not. I'm not discussing any isolation level. I just posted the link and quoted few lines from the link (not my words or my discussion, if that is what you mean when you say "I were discussing isolation level").
not have been any need for all this argument. Why MSActually, many, many moons ago, Oracle create varchar2 to distinguish from IBM's varchar datatype. The IBM definition was embedded in an ANSI standard and that was the reason for Oracle creating varchar2. (At least that was what Oracle developer and PM told me at the time - mid 80's). No idea how Sybase (and it's spawn, MS SQL Server) handle varchar in comparison to the IBM definition.
Varchar and Oracle Varchar2 in the first place if
they are not going to mean the same. The issue about
The docco in Oracle 5 and 6 explicitly stated the difference. (The difference is in comparison semantics - indicating whether shorter strings get padded to perform the comparison.)
Besides - is there any RDBMS out there that is truly and fully ANSI SQL compliant? To any version of ANSI SQL? <g>
Just like any other tool, you simply gotta learn the tool and know how to work around the shortcomings.
> The docco in Oracle 5 and 6 explicitly stated the difference. (The difference is in comparison
semantics - indicating whether shorter strings get padded to perform the comparison.)
Surely VARCHAR and VARCHAR2 were new in 7.0 (1991), along with the blank-padded CHAR type. Previously VARCHAR was a synonym for CHAR, which used to be a variable-length string with a maximum length of 255 bytes. Every version of the documentation since then has explained the difference.
Although null values frequently cause problems in data retrievals, they can sometimes be used to increase performance.
Consider the case of a very large table (20,000,000 rows) to which new records are added daily (usually about 1,000 of them). Every night, you need to report these additions on an audit trail. Rather than scan the whole table looking for changes, you will want to use an index over the TRANSACTION_DATE column. But the index would need to be huge. This is a case in which your index is over the entire table, although you are actually interested only in the 1,000 or so records that were added today. The actual index is physically many times larger than it needs to be, and it uses many more disk I/Os to traverse the binary tree to the leaf data.
Now suppose you add a smaller (one-character) column to the table. This column distinguishes between the records that need to be printed and the records that do not need be printed; the column would contain "U" for unprinted and "P" for printed. This gives you a good way to find the records you are looking for. Although the index isn't as large as was required in the previous example, it still contains 20,000,000 entries. All this just to find the 1,000 that you need to print.
By taking advantage of the special qualities of null, you can avoid having to store and maintain all of these index entries. When the print job actually prints the new records, it prints each record containing a "U" flag. Once the record has printed successfully, the print routine resets this column to null, thus removing all references to those unprinted (and not new) records from the index. The index will never grow any larger than the approximately 1,000 records you have added today. By doing this, you reduce the expected size of the index from approximately 20 megabytes to 20 kilobytes. The reduction in size easily justifies the additional overhead (a new subindex and an extra column update) associated with it.