Thanks Albert. I've become aware that the SELECT top 1 syntax works well also. Again, my goal is to determine why I'm getting "235 - Insufficient space to process" errors on wide variety of code that works the vast majority of the time. Seems it would be "environmental" in that something is being done systemically that shouldn't be and causes instability.
Thanks again. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Albert Berry Sent: Friday, August 20, 2010 3:28 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: ERROR 235 - Insufficient space to process command 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 > > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3051 - Release Date: 08/15/10 23:35:00
