I think 2059 errors and the errors that result from dropping
non-existent temp tables/views and similar are acceptable. If I can,
however, within a single command alter the syntax to eliminate an error
I do, as in the example I gave below. I routinely do drop error 2059,
and I routinely use the LIMIT clause when all I need to know is that at
least one row exists. I don't know if the repetitive error generation
would cause a fatal exit. Razzak and crew may have an answer for that.
In the case of LIMIT, it is the fastest way to check for one or more.
The command is satisfied the first row it hits.
Albert
Steve Martin wrote:
Thanks Albert. Modifying the logic so that no errors would ever be
generated is doable. What I'm trying to determine is if it's necessary
for stability. Another example would be setting off 2059 (no rows
satisfy the where clause) prior to executing a command that might return
no rows as opposed to preceding the command with an additional select
count(*) in order to not risk generating the 2059 error.
Is the rule of thumb "don't ever cause an error to be generated" or can
we allow them, suppress them from the interface and utilize the
performance advantage?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Albert
Berry
Sent: Friday, August 20, 2010 2:32 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: ERROR 235 - Insufficient space to process
command
If you suspect more than one row might appear, don't turn the error off,
use LIMIT instead.
SELECT CustCity from Customers where CustID = 123 and LIMIT = 1
This will return only the first row found, which is what would happen
anyway, but will generate no error messages
Albert
