On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
I noticed that the procedure 'Dumb_Withdraw_tr' actually takes @UpdatedDtm as a parameter
On Wednesday, 28 July 2021 at 10:49:58 UTC+10, Derek Ignatius Asirvadem wrote:knowledge, and that is HYPOTHESIS, which when confirmed by tests is elevated to THEORY. If and when the theory is proved (proper proof, proper method, not merely a mathematical definition of a theory), it progresses to a truth, and is added to that body
On Tuesday, 27 July 2021 at 21:37:57 UTC+10, Nicola wrote:
Here is my take on science, as it has been 350BC to 1911. (Which is under attack since 1911, by Modernism.) It is a body of knowledge (certainty: the Latin word means knowledge not speculation). Of course, one can speculate BASED ON that body of
When that theory, which is proved in one or the other vertical gets proved in many verticals, it is elevated to LAW, such as the LAW of Thermodynamics, and it applies to all other sciences. Eg. evolutionism fails the second LAW of Thermodynamics.
<<<
On Wednesday, 4 August 2021 at 19:23:53 UTC+10, Derek Ignatius Asirvadem wrote:each SQL Platform supplier has extensions. In contrast the freeware has substitutions, and a whole pile of extensions that are irrelevant, that ensure that the code is not portable.
Noting that what you are used to, the PoopDePooGres "sql" is *not* SQL, and certainly *not* a programming language, but we have had SQL since IBM released it into the public domain. It is the Relational data sub-language defined by Codd. Of course,
With a view to learning what actually SQL is, that it is a full programming language, and specifically what SAP/Sybase Adaptive Server Enterprise [ Transact-SQL ] is, please erase all your notions of SQL; ACID; Transactions that you have acquired, andstart with a fresh and open mind. The obstacle to learning this is, as always, any attitude that you know the subject matter, and eg. you just need to learn the Sybase syntax. In particular, do not attempt to perform a task in Sybase in the pig poop way,
1. Visit this page
__ https://help.sap.com/viewer/product/SAP_ASE/16.0.4.0/en-US?task=whats_new_task
2. Select [ Download PDFs ] at top right
3. Choose the manuals you want, and download them. Read them from cover to cover. On the train or whatever.
4. I recommend the following, in order.
__ Installation & Upgrade Guide
__ Transact-SQL Users Guide
__ Reference/Building Blocks
__ Reference/Commands
__ Reference/Utility (especially isql)
__ Admin/System Admin Guide/Volume 1
1. Read the Transact-SQL Users Guide
____ at least ch 20 Transactions: Maintaining Data Consistency and Recovery
2. Then read my guide to the Lock Manager
____ https://www.softwaregems.com.au/Documents/Article/Sybase%20Lock%20Manager/Sybase%20Lock%20Manager.pdf
All my Sybase docs are condensed, intended for Sybase DBAs. I have
just updated it, and added a bit of detail, imp[roved the clarity, so
as to be relevant for novices.
Remember, this is a serious Lock Manager, not comparable to your 2PL
filth, which has to be asserted because you guys position commercial
SQL Platform Lock Managers as your "2PL" filth, and insist that we
have your insane problems. It is so mature and secure, so brilliant
in architecture, that it has not changed since 1984. Extended, yes
(eg. to handle new Lock Types to support SAP files, eg. add row locks;
etc), but changed, no. So read these docs with a fresh mind, to not
take your academic baggage with you.
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
Nicola
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the lenght of the answer, which yet again has to be
an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as
a teaching professor) can glean from the article.
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
Nicola
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the lenght of the answer, which yet again has to be
an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as
a teaching professor) can glean from the article.
To me that stuff reads as fake as the fake it claims to depict.
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the length of the answer, which yet again has to be
an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as
a teaching professor) can glean from the article.
Nicola
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
Nicola
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the lenght of the answer, which yet again has to be
an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as
a teaching professor) can glean from the article.
To me that stuff reads as fake as the fake it claims to depict.
Yes, of course the tv show is fake.
Yes, of course the concept is fake (Big Brother, "progressed" 15 years).
That is obvious.
That aside, did you glean anything of value from the article ?
Nicola
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the length of the answer, which yet again has to be
an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as
a teaching professor) can glean from the article.
Another simple question, clarifying only, in order to reduce my labours.
Given your detailed question, AND the example you have cited, at what
point in time, do you suggest that the COUNT() would be correct
? I am not asking for a long answer here, just clarifying you query.
A few words would be enough.
On Wednesday, 11 August 2021 at 19:14:58 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the length of the answer, which yet again has to be >> > an explanation for you, please read this newspaper article. Explain
in one or two sentences, what it the most important item that you (as >> > a teaching professor) can glean from the article.
Another simple question, clarifying only, in order to reduce my labours.
Given your detailed question, AND the example you have cited, at what point in time, do you suggest that the COUNT() would be correct
? I am not asking for a long answer here, just clarifying you query.
A few words would be enough.
If transaction T1 is scanning a table to count its rows, and
concurrently transaction T2 removes one row and adds two, the only
values T1 should be able to compute are N (the number of rows in the
table before the T1 and T2 starts executing) and N+1. That is because
there are two possible serial executions:
I wouldn't talk about some "point in time when count() is correct".
Logically, the count is (should be) an atomic (so, logically
instantaneous) operation,
so whenever T1 commits, that's when the count
becomes visible, and its result should be correct at that point.
so whenever [S1] commits, that's when the count
becomes visible, and its result should be correct at that point.
Note, that if [T1] was a Transaction, then it would be SERIALIZABLE, and the desperately fantasised “problem” would not occur.
I wouldn't talk about some "point in time when count() is correct".Now you are saying:
its result should be correct at that point.
Read committed permits an execution in which:Corrected:
1. T1 starts scanning the table, counting the row that T2 will delete;
1. [S1] starts scanning the table, counting the row that T2 will delete;
1. [S1] starts scanning the table, counting the rows, oblivious to other activity, by virtue that it declaratively runs at READ COMMITTED.
Note, that if [T1] was a Transaction, then it would be SERIALIZABLE, and the desperately fantasised “problem” would not occur.
2. T2 executes and commits;Corrected:
3. T1 keeps scanning the table, now counting the rows that T2 has added.
3. [S1] keeps scanning the table, without regard to other activity
Then, T1 would return N+2, where the table never had N+2 records.
Then, [S1] would return N+2
Count() would return the correct result if and only if the returned
value is among the values that some serial execution of the same set of committed transactions would have returned.
- T1;T2, in which case T1 would count N rows;Corrected:
- T2;T1, in which case T2 would count N+1 rows.
- [S1];[T2], in which case [S1] would count N rows;
- [T2];[S1], in which case [T2] would count N+1 rows.
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
On 2021-08-06, Derek Ignatius Asirvadem wrote:
Btw, with a mention of how that affects joins. That, plus this (which
is about SQL Server and has some inaccuracies, but overall I think it
is relevant):
https://sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level
makes me conclude that in general you do not have statement-level consistency at read committed in SQL Server or ASE.
But good graduate students would have no problems grasping such details
(or those of any other system), capitalizing on their academic baggage.
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
On Wednesday, 11 August 2021 at 18:45:32 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
On Wednesday, 11 August 2021 at 06:14:10 UTC+10, Nicola wrote:
On 2021-08-10, Derek Ignatius Asirvadem wrote:
Nicola
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
In order to reduce the length of the answer, which yet again has to be >> > an explanation for you, please read this newspaper article. Explain
in one or two sentences, what is the most important item that you (as >> > a teaching professor) can glean from the article.
To me that stuff reads as fake as the fake it claims to depict.
Yes, of course the tv show is fake.
Yes, of course the concept is fake (Big Brother, "progressed" 15 years). That is obvious.
That aside, did you glean anything of value from the article ?
No.
On Sunday, 8 August 2021 at 23:52:04 UTC+10, Nicola wrote:
On 2021-08-06, Derek Ignatius Asirvadem wrote:
1. Read the Transact-SQL Users Guide
____ at least ch 20 Transactions: Maintaining Data Consistency and Recovery
2. Then read my guide to the Lock Manager
____ https://www.softwaregems.com.au/Documents/Article/Sybase%20Lock%20Manager/Sybase%20Lock%20Manager.pdf
All my Sybase docs are condensed, intended for Sybase DBAs. I have
just updated it, and added a bit of detail, imp[roved the clarity, so
as to be relevant for novices.
Remember, this is a serious Lock Manager, not comparable to your 2PL filth, which has to be asserted because you guys position commercial
SQL Platform Lock Managers as your "2PL" filth, and insist that we
have your insane problems. It is so mature and secure, so brilliant
in architecture, that it has not changed since 1984. Extended, yes
(eg. to handle new Lock Types to support SAP files, eg. add row locks; etc), but changed, no. So read these docs with a fresh mind, to not
take your academic baggage with you.
I have read a couple of documents (the T-SQL guide and the Locking and Concurrency Control manual).
My takeaways:
- yes, it is a serious lock manager (I did not expect anything less from
a high-end commercial product).
- I did not find any concept that you would not find in a database
systems' textbook (and no, the Alice's book is not such a textbook).
- Call it what you like, but ASE/Sybase uses what is known as "rigorous
2PL" to implement repeatable read and serializable:
https://help.sap.com/viewer/a08646e0736e4b4b968705079db4c5f5/16.0.3.7/en-US/a8ea3fd4bc2b1014b6569e800f6bba42.html.
- Call it what you like, but ASE/Sybase uses what is known as "rigorous
2PL" to implement repeatable read and serializable:
"Applying exclusive locks [...] until the end of the transaction.
Applying shared locks [...] until the end of the transaction".
Textbook definition of rigorous 2PL.
- It uses index-locking to prevent phantoms. Again, no surprise and
pretty much standard textbook material.
- There is a section dealing exactly with the question I have posed: "Locking for Select Queries at Isolation Level 1"
https://help.sap.com/viewer/a08646e0736e4b4b968705079db4c5f5/16.0.3.7/en-US/a8eb04a3bc2b1014bef8884d8400b0ab.html
Btw, with a mention of how that affects joins.
That, plus this (which
is about SQL Server and has some inaccuracies, but overall I think it
is relevant):
https://sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level
makes me conclude that in general you do not have statement-level consistency at read committed in SQL Server or ASE.
ASE is a fine implementation (*), based on concepts that have been very
well known in the academic community for a long time
(not to say that
they are obsolete! On the contrary!). What's not in the textbooks is the specific implementation details and system-dependent guidelines that
a manual is expected to provide. Granted, the devil's in the details.
But good graduate students would have no problems grasping such details
(or those of any other system), capitalizing on their academic baggage.
(*) Known to the academics. E.g., some time in the '90s, Sybase was used
for lab exercises at Stanford.
Given your detailed question, AND the example you have cited, at what
point in time, do you suggest that the COUNT() would be correct
? I am not asking for a long answer here, just clarifying you query.
A few words would be enough.
If transaction T1 is scanning a table to count its rows, and
concurrently transaction T2 removes one row and adds two, the only
values T1 should be able to compute are N (the number of rows in the
table before the T1 and T2 starts executing) and N+1. That is because
there are two possible serial executions:
False. We are not serialised.
We are discussing READ COMMITTED,
1. [S1] starts scanning the table, counting the rows, oblivious to
other activity, by virtue that it declaratively runs at READ
COMMITTED.
2. T2 executes and commits;
3. [S1] keeps scanning the table, without regard to other activity
Which somehow is “incorrect” to you.
Count() would return the correct result if and only if the returned
value is among the values that some serial execution of the same set of
committed transactions would have returned.
I reject that as a definition, Sybase; DB2; MS rejects that as well.
Wherein COUNT at READ COMMITTED works perfectly.
But there is an important second point: anyone who has even pedestrian knowledge of SQL on a genuine SQL Platform, would know that [separate
to the count changing constantly because the table is active], that
that is not a “problem”, that that is not the way to obtain a COUNT on
a large table.
On Thursday, 12 August 2021 at 18:52:19 UTC+10, Nicola wrote:
On 2021-08-11, Derek Ignatius Asirvadem wrote:
Given your detailed question, AND the example you have cited, at what >> > point in time, do you suggest that the COUNT() would be correct
? I am not asking for a long answer here, just clarifying you query.
A few words would be enough.
If transaction T1 is scanning a table to count its rows, and
concurrently transaction T2 removes one row and adds two, the only
values T1 should be able to compute are N (the number of rows in the
table before the T1 and T2 starts executing) and N+1. That is because
there are two possible serial executions:
False. We are not serialised.
We are discussing READ COMMITTED,
Ok, I have misunderstood your question.
The above is a very informally
stated definition of correctness of a schedule (i.e., serializability).
So, if you ask at what point in time a result of a query run at READ COMMITTED is correct, the answer is: in general, never.
Note that this
answer doesn't rule out situations in which you can guarantee a correct result even at that level.
1. [S1] starts scanning the table, counting the rows, oblivious to
other activity, by virtue that it declaratively runs at READ
COMMITTED.
2. T2 executes and commits;
3. [S1] keeps scanning the table, without regard to other activity
Which somehow is “incorrect” to you.
Yes, according to the definition of "correctness" (which you affirm to reject) as equivalence to a serial schedule.
Sorry, what is the definition of "correctness" according to the
Standards?
Yes, you can and you have, which is why your fantasy such as “MVCC” is now a COLLECTIVE fantasy, the expectation of the unqualified “developers”.
Count() would return the correct result if and only if the returned
value is among the values that some serial execution of the same set of >> committed transactions would have returned.
I reject that as a definition, Sybase; DB2; MS rejects that as well.
Then, again, please provide a definition of "correctness". Because you
want to be confident that your queries produce "correct" results, don't
you?
Since anything can happen concurrently during the execution of a query
at READ COMMITTED, how can you tell apart the result of a query
returning an integer from
select cast(rand() * 1000000) as int)
?
Wherein COUNT at READ COMMITTED works perfectly.
Ok if you are referring to other ways of counting.
But if you mean that
counting by scanning the table at READ COMMITTED works perfectly,
please
elaborate on what "works perfectly" means.
But there is an important second point: anyone who has even pedestrian knowledge of SQL on a genuine SQL Platform, would know that [separate
to the count changing constantly because the table is active], that
that is not a “problem”, that that is not the way to obtain a COUNT on a large table.
Sure. But it still illustrates the point, which is about the kind of
issues you may run into when running queries at READ COMMITTED.
It is
not suggesting that you *should* run those queries at READ COMMITTED.
Counting was not the best example; but you can replace the query with
some other computation.
On Thursday, 12 August 2021 at 16:08:28 UTC+10, Derek Ignatius Asirvadem wrote:
Make no mistake:
__ Truth = Reality = life
__ Falsity = Rejection of Reality = death
__ Sanity = conforming the intellect to Reality
__ Insanity = desperately try to conform reality to the mind, which after a lifetime of failure, ends in suicide.
Academics foster death. It is evil.
On Friday, 13 August 2021 at 13:37:40 UTC+10, Derek Ignatius Asirvadem wrote:is the core principle that caused the impotence of academics in this field for FIFTY years (no progress of the /Relational Model/, but hundreds of anti-Relational papers marketed as “Relational”).
It is stupefying, idiotic, insane, to define “correct” as an abstraction without reference to reality, and then try to apply it to reality, but academics love abstraction with no relation to reality, it is the foundation for their fantasies. This
Those who are so intellectually crippled, insist that we who are not crippled, should be so crippled, so that OUR operation is “correct” according to cripples.
On Thursday, 12 August 2021 at 16:08:28 UTC+10, Derek Ignatius Asirvadem wrote:
Make no mistake:
__ Truth = Reality = life
__ Falsity = Rejection of Reality = death
__ Sanity = conforming the intellect to Reality
__ Insanity = desperately try to conform reality to the mind, which after a lifetime of failure, ends in suicide.
Academics foster death. It is evil.
On Friday, 13 August 2021 at 13:37:40 UTC+10, Derek Ignatius Asirvadem wrote:is the core principle that caused the impotence of academics in this field for FIFTY years (no progress of the /Relational Model/, but hundreds of anti-Relational papers marketed as “Relational”).
It is stupefying, idiotic, insane, to define “correct” as an abstraction without reference to reality, and then try to apply it to reality, but academics love abstraction with no relation to reality, it is the foundation for their fantasies. This
Those who are so intellectually crippled, insist that we who are not crippled, should be so crippled, so that OUR operation is “correct” according to cripples.
Are there any facts, in my Transaction Sanity doc, p1 and p2, that you dispute ?
On Monday, 16 August 2021 at 19:29:04 UTC+10, Nicola wrote:
On 2021-08-15, Derek Ignatius Asirvadem wrote:
Are there any facts, in my Transaction Sanity doc, p1 and p2, that you dispute ?
How could I dispute facts?
Thank you for that document, and for the whole discussion around ACID
and transactions.
It has made me understand how you use those terms (as
opposed to their "textbook" use),
which in turn, has helped me clarify
many aspects of your critique of MVCC.
I'll gladly follow your developments on Dan's data model, if there are
any,
and think how they (fail to) apply to MVCC-based systems.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 55:31:29 |
Calls: | 6,650 |
Calls today: | 2 |
Files: | 12,200 |
Messages: | 5,330,754 |