Karen:
As ever, I appreciate your eye to the possibilities here.
My default is to assume that all anti-social eruptions in my programs result from undisciplined coding and inconsistent maintenance practices (have teenagers?). A comparison of my coding to Razzak's posting suggests this may be the case here.
This routine has run in production for over a month within a very TRACEd set of programs. The errors surfaced while fitfully introducing TEST/LIVE toggles (IF vopmode = 'TEST' ...) into a prehistoric routine testing for tables such as 'pksimport', which exist only if the last session crashed. There were limited, but real opportunities for sys_mayhem as I had several crashes while upgrading. It is VERY possible that I've not accounted for dependent views in my end-of-program cleanup routine; and that my upgrade session created the very conditions you suggest. So, more to do.
My immediate solution? Punt:
SET ERROR MESSAGE 2038 OFF
DROP TABLE pksimport
SET ERROR MESSAGE 2038 ON
My new best friend.
Thanks
-------- Original Message --------
Subject: [RBASE-L] - Re: Error Source Mystery
From: [email protected]
Date: Mon, September 03, 2012 7:07 am
To: [email protected] (RBASE-L Mailing List)
I have a suggestion, but I'll admit I'm not 100% sure I'm right. I believe
that sys_tables is an internal table generated by RBase as it is needed
(correct me if I'm wrong, Razzak). If any of those tables or views have
errors in them, you can get error messages as it is trying to generate the
sys_tables internal table. I've often seen views that are no longer valid,
they are old views and reference columns/tables that no longer exist, or
they refer to variables that are not defined (something I try to avoid whenever
possible). If you trace a program that has a Gateway Import in it, and RBase
goes thru its long process of validating database schema before the import
begins (something I frankly wish it wouldn't do), you will see error messages
for any invalid views. So maybe that's creating those messages?
Karen
In a message dated 9/2/2012 1:20:54 PM Central Daylight Time, [email protected] writes:
I'm up and running, so this is for understanding only.
For reasons obscure and unclear, the following code produces two errors, interrupting TRACE processing:
SET VAR +
vimporttable TEXT = NULL, +
vtargettable TEXT = NULL, +
vsystablecount INTEGER = NULL
SET VAR +
vimporttable = 'pksimport', +
vtargettable = .vimporttable
SELECT COUNT (*) +
INTO vsystablecount IND iv1 +
FROM sys_tables +
WHERE sys_table_name = .vtargettable
"ERROR-I/O Problems-Check for a full disk. (2009)"
"ERROR-Database files are out of sync. (2520)"
Hmmm.
