All: Yep. That explains precisely what I was seeing, in particular the 'Resource Unavailable' messages.
Recommendations taken and appreciated. Bruce -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of A. Razzak Memon Sent: Monday, July 08, 2013 9:57 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DROP TABLE Confusion At 12:25 AM 7/9/2013, James Bentley wrote: >Bruce, >I would move the DROP CURSOR c1 command to just after setting the error >messages off. The reason to do this is that the CURSOR might use some >of the tables you are attempting to drop. If a table is part of a >CURSOR a DROP TABLE command will fail in the CURSOR is still defined. Programmatically, you could also take advantage of the newly introduced (CHKCUR('cursorname')) function, if you wish. (CHKCUR('cursorname')) checks to see if a cursor is declared and is not dropped. The function returns an integer value of 1 if the name exists and is not dropped, and 0 if it is not declared or dropped. -- Example IF (CHKCUR('c1')) <> 0 THEN DROP CURSOR c1 ENDIF This is as simple as it can get. A declared cursor must be dropped prior to dropping the table/view. Internal Lock Error, Resources Unavailable Error, and I/O Errors are the result of such mismanagement. Very Best R:egards, Razzak. www.rbase.com www.facebook.com/rbase -- 30+ years of continuous innovation! 15 Years of R:BASE Technologies, Inc. making R:BASE what it is today! --
