Subject Re: [firebird-support] exists(EXECUTE STATEMENT ...
Author Helen Borrie
At 12:09 PM 16/08/2004 +0200, you wrote:
>Yes, and count(*) will always move through the whole result set.
>Therefore I wanted to use EXISTS.

It was right to use EXISTS, just wrong to suppose that EXISTS(EXECUTE
STATEMENT....) is valid syntax. I don't remember the details of your
statement now, but you could do something like this:
declare truefalse smallint;
sql = '(select '||fieldname||' from '||tablename|| ' ';
sql = sql || 'where '||searchfield||' = '||variable||')';
sql = 'select 1 from rdb$database where exists '||sql;

if (truefalse = 1) then

>HB> Saving on keystrokes and improving visual clarity isn't laziness...clean
>HB> coding conventions are much more readable than double quotes and the
>HB> problems associated with them.
>Which problems?
>I don't have any with quotes.
>Ok, when using Perl or PHP you have to be a little bit careful... :-)

1. When using *any* client interface you have to be a LOT careful, both to
include the quotes and to get the case right, in EVERY reference to an
object with quoted identifiers.
2. In Perl and PHP and several other languages, you have to escape double
quotes in literal strings such as SQL statements.
3. Best practice in SQL is supply column lists for all SELECT statements,
so that it is simpler to mend apps that you break by changing
metadata. Apart from the untidiness, extra opportunity for errors, you add
two extra bytes for every object referred to (and two extra hits on the
Shift key!)
4. The length of a statement is limited so wasting bytes doesn't make
sense. (The length of a plan is even more limited, so you don't want to
waste bytes there, either).
5. For me (as a Pascal programmer) they break the standard Pascal coding
conventions which I, along with most Pascal coders, follow. Java coding
conventions are similar to Pascal's. I HATE having to handle code written
by people whose only justification for using these infernal quotes is to
enable case-sensitive identifiers. Non-C programmers get along admirably
despite lacking the ability to code hidden traps like two variables named
first_name and FIRST_NAME.

Now, you tell me what's *good* about them.