Re: Counting propositions

"Laconic2" <laconic2_at_comcast.net> wrote in message news:CsadnRUdme46dlDdRVn-hA_at_comcast.com...
> If I remember my DEC Rdb/VMS from ten years ago right, (a big if), the
> translation of SQL was in two stages...
>
> The first stage parsed the SQL and translated it into something called BLR
> (Binary Language Representation). This might be done by a precompiler or
by
> an SQLMOD compiler. BLR was an intermidiate representation of the query,
> but not the plan for executing it. The second stage involved actually
> turning the BLR into an executable execution plan. This was done the
first
> time the query was run.
>
> If I remember right, the BLR did not contain any wildcards. Thus the
> original intent to mean "I want all the columns, what ever they are" is
> missing from the BLR. The BLR is data independent of the addition of new
> columns.
>
> Now let's say that after you "compile" the source program, but before
you
> execute it, along comes a DBA that has stopped taking his meds. In a
manic
> mood, he adds a new column, fills in the value "0" for the existing rows,
> drops the primary key constraint, and adds a new primary key constraint
> that includes the new column. Why would he do that? I dunno!
>
> Now we run the previously compiled query. It can deliver a different
result
> from "select count(*)" !

If query doesn't return the correct snapshot of the database state at the moment query was issued for execution, then it's execution bug. Cursor sharing (implemented in virtually every RDBMS) is a lame excuse for introducing this kind of confusion. I even suggest that invalidating the cursor is an easy fix. Received on Mon Jun 14 2004 - 20:46:28 CEST