Many thanks, Razzak, and Mike & Dennis.
(Please note: I have quoted some words that are easier to use and are _not_
meant to be criticisms but I have not quoted every use as it would drive us all
mad to read it.)
Because I renamed the database with the “errors” to: Gen_Err and reloaded to
the original name I still have the database with the “errors”.
Unload All / Load the output file with feedback on from Gen_Err produced no
errors. I wouldn’t expect it to because, according to Autochk, there are
deleted rows which are not going to be unloaded and therefore not counted on
the load back to a new database.
As Dennis pointed out the Autochk total active and deleted = the total counted.
It seems that amending a table, maybe a particular type of change it’s true,
seems to be producing the deleted rows in the four system tables which, I
presume, should not show anywhere as “errors”. They don’t have an incorrect
number of rows, they have so many active, so many deleted and a total which is
mathematically correct.
Examining data in SYS_COMMENTS Rows: Active 194, Deleted 28
Actual rows counted: 222, expected count: 194
Is the Actual rows counted wrong? No, it’s the total of active and deleted.
Is the expected rows counted wrong? It’s the same as the Active count which
seems logical?
The Active and Deleted counts are presumably right.
The Expected count doesn’t include the deleted rows and:
Autochk pauses four times, however, with the message: -Error – The number of
rows counted was not expected (1254)
and ends with: Errors have been encountered.
(I don’t suppose it’s relevant but the three tables that had recently been
amended in Gen_Err now appear after the “Examining Views” section of the
Autochk output rather than before that section with the other tables. They are
also after the views in the newly reloaded original name db, General, with no
errors reported. However, in the db created by unload/load, Gen_Raz, they are
back in the expected place before the views and no errors reported.)
Anyway, I assume Autochk must be giving the actual info correctly. Yet when
using RELOAD those same four system tables with deleted rows in Autochk are
also reported by reload as having the incorrect number of rows. But one of the
reasons for using reload is to get rid of any deleted rows and reduce space.
R>reload xxx
-ERROR- Table SYS_COMMENTS has an incorrect number of rows. ( 450)
-ERROR- Table SYS_DEFAULTS has an incorrect number of rows. ( 450)
-ERROR- Table SYS_COMPUTED has an incorrect number of rows. ( 450)
-ERROR- Table SYS_CONSTRAINTS has an incorrect number of rows. ( 450)
Finished reloading with 4 error(s).
RELOAD operation is complete
It would appear, jumping to conclusions, that reload is having some “problem”
with reporting deleted rows as being counted. As nobody else appears to be
having anything similar I guess there must be something odd in my database
despite unload/load not producing any hints as to what.
I’m puzzled, because to my mind, those are not “errors” but deleted rows being
ignored as they should be. I am only noticing this because my RMD file that has
done numerous regular reloads of five databases over many years has recently
been exiting with the ErrVar set after the completion of a reload where I have
amended a table. That RMD file was last amended 29/07/2010.
The relevant code is simple enough where the variable contains the name of the
current database and the path/name of the new one:
RELOAD .vDBtoReload
SET VAR vError = .vErrVar
IF vError <> 0 THEN
DISCONNECT
SET VAR vMessage = +
('Error creating new backup database:' & .vDBtoReload)
It works perfectly unless there are real errors, obviously, or these “rogue”
counts. I can correct the rogue counts simply by reloading manually at the R:>
and ignoring them or by the Unload/Load route. At least once a year all my
databases are fully reconstructed using the unload/load route to weed out any
errors but I don’t recall when the last time was that I had anything to correct
over some years now. Every time I go to the R:> Autochk is automatically run on
the database I intend to use and, again, errors are very rare except for this
recent oddity. Should anything show up it gets corrected there and then!
Next time I amend a table I’ll try to remember to note everything I do and then
run Autochk & reload and see if the same weird thing happens.
Thanks again for the advice,
Regards,
Alastair.
From: A. Razzak Memon
Sent: Saturday, July 20, 2013 8:41 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Autochk query (and an unrelated mysteriousfix)
At 01:27 PM 7/20/2013, Alastair Burr wrote:
>... what is causing me the real problem is that RELOAD exits with these
>errors and sets the ErrVar to the error number.
>
>R>reload xxx
>-ERROR- Table SYS_COMMENTS has an incorrect number of rows. ( 450)
>-ERROR- Table SYS_DEFAULTS has an incorrect number of rows. ( 450)
>-ERROR- Table SYS_COMPUTED has an incorrect number of rows. ( 450)
>-ERROR- Table SYS_CONSTRAINTS has an incorrect number of rows. ( 450)
>Finished reloading with 4 error(s).
>RELOAD operation is complete
>
>Any thoughts?
Alastair,
Got R:Scope 9.5 (32/64)?
If not, UNLOAD and then Re-Build the database and see what you observe.
Here's a very simple exercise to check the health/integrity of the database.
Note: Make a backup copy of your database before following the steps below.
-- At the R> Prompt
SET MESSAGES ON
SET ERROR MESSAGES ON
DISCONNECT
CONNECT dbname IDENTIFIED BY owner password
OUTPUT ABC.ALL
UNLOAD ALL
OUTPUT SCREEN
DISCONNECT
RENAME dbname.rb? dbbackup.rb? -- 9.5 (32)
RENAME dbname.rx? dbbackup.rx? -- 9.5 (64)
SET FEEDBACK ON
RUN ABC.ALL
SET FEEDBACK OFF
Watch the database being re-build right in front of your eyes.
Notice any -ERROR-s, if any, and handle those specific items accordingly.
With a corrupted database schema or data, you may check the health/integrity
of your database using the two-step process as follows:
-- Step 01 (Unload Database Schema)
DISCONNECT
CONNECT dbname IDENTIFIED BY owner password
OUTPUT ABC_STRUCTURE.ALL
UNLOAD STRUCTURE
OUTPUT SCREEN
-- Step 02 (Unload Actual Data)
OUTPUT ABC_DATA.ALL
UNLOAD DATA
OUTPUT SCREEN
DISCONNECT
RENAME dbname.rb? dbbackup.rb? -- 9.5 (32)
RENAME dbname.rx? dbbackup.rx? -- 9.5 (64)
-- First Re-Build the Database Schema
CLS
RUN ABC_STRUCTURE.ALL
Watch the database schema being re-build right in front of your eyes.
Notice any -ERROR-s, if any, and handle those specific items
accordingly by manually editing the ABC_STRUCTURE.ALL file.
Make sure to delete the dbname.rb? or dbname.rx? prior to running
the ABC_STRUCTURE.ALL again.
Repeat this step until you have a perfect database database schema
with no -ERROR-s using the TRACE option as follows:
CLS
DISCONNECT
DELETE dbname.rb? -- 9.5 (32)
DELETE dbname.rx? -- 9.5 (64)
TRACE ABC_STRUCTURE.ALL
Make sure to delete the dbname.rb? or dbname.rx? prior to TRACing
the ABC_STRUCTURE.ALL again.
-- Once the database schema is built with no errors, then load the data
CLS
SET FEEDBACK ON
RUN ABC_DATA.ALL
SET FEEDBACK OFF
Hope this simple exercise/steps provides you with some blue's clues!
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!
--
