Re: Is Oracle deliberately difficult?

Yes, still they (use DBMS & COBOL) follow batch processing, applications are designed such a way
that reading and updating/Inserting is not on the same table (database). Applications are designed
and business process is planned to overcome the difficulty of consistancy (I personally feel it is more efficient). Now I need to tell you why Oracle (RDBMS) is better than so called DBMS & COBOL with respect to read consistancy.

1. Say You have fired a query @ 11 AM which returns a report where your bussiness requirement is such that if line one in the report = 'X' then line 50 should be 'Y'. @ 11:01 AM somebody fires a query which updates row 1 = 'X' and row 50 = 'Y' (obviously, it is business rule) in a single transaction and is commited immediately. By the time Your query started @ 11 AM finished reading 1 row and prints in the report that line one is 'N' and comes to 50th row which then your Query reads updated value of row 50 then prints line 50 as 'Y'. There you failed in on-line transaction processing systems if Oracle is not smart.
2. Do you think if many people are inserting rows in a Order table so fast and somany that a person who is trying to take a list of all orders will see his report kept printing never ending (may not be that practical)

Jay M. Scheiner <jxs_at_wolpoff_nospam_law.com> wrote in message news:39b66155.930802942_at_news.erols.com...
> No, you are misunderstanding the concept of a transaction & what I am
> saying. If someone goes into a transaction, performs their changes &
> gets out (data is consistent) then my report will be correct. This
> concept has worked fine for non-relational databases for decades.
> Plenty of big businesses (as in, probably your bank, your insurance
> company, etc.) still use Cobol on mainframs.
>
> On Wed, 6 Sep 2000 14:06:53 +0100, "Dasari" <sbabudas_at_ford.com> wrote:
>
> >You are trying to challenge One of the important features of RDBMS, If
 you
> >cannot accept be prepared to see unbalanced accounts (balance sheet),
 Your
> >company will fire you for producing such a report.
> >
> >
>
>
> _______________
> Jay M. Scheiner
> Programmer/Analyst
> Wolpoff & Abramson, LLP
> remove _nospm_ from email address
> Opinions are my own only!
Received on Thu Sep 07 2000 - 04:56:37 CDT