At 04:37 AM 7/21/2013, Alastair Burr wrote:
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.
Alastair,
Just having deleted records in tables should not
generate errors when performing an AUTOCHK.
Since the errors are located in the SYSTEM
TABLES, it appears that one or more tables were
incorrectly dropped at some point. Perhaps the three you mention above.
The corruption could have occurred from the table
being in use while the drop was attempted,
perhaps in new untested code, or during possibly
network connection issues. If the error
becomes more frequent, then there would be an area for concern.
From the errors, you may possibly pinpoint the source table(s):
Examining data in file #2...
Examining data in SYS_COMMENTS Rows: Active 194, Deleted 28
Actual rows counted: 222, expected count: 194
Examining data in SYS_DEFAULTS Rows: Active 27, Deleted 1
Actual rows counted: 28, expected count: 27
Examining data in SYS_COMPUTED Rows: Active 20, Deleted 2
Actual rows counted: 22, expected count: 20
Examining data in SYS_CONSTRAINTS Rows: Active 81, Deleted 2
Actual rows counted: 83, expected count: 81
Do you have a regular routine which specifically
creates/drops a table containing 28 comments,
1 default value, 2 computed columns, and 2
constraints? With the three tables, is there a
combination of the three that equate the same?
Other than using PACK, RELOAD, or UNLOAD to
rebuild the database and resolve the issues, more
questions will be answered by looking into the
database structure and rows with R:SCOPE.
http://www.rbase.com/products/rscope95/
R:SCOPE checks the database structure and data
pointers but also includes database correction
features.
Specific to the above errors, R:SCOPE will allow
you to review the contents of deleted records
before the PACK, RELOAD, or UNLOAD will
permanently deletes the files. And, the actual/expected
row count can be reset within the R:SCOPE table structure repair options.
With R:SCOPE you will know the possible damage
right away! The documentation includes detailed
information about R:BASE database file structure
and data storage. Once you are familiar with
R:SCOPE, you can use it to check your database on
a regular basis. Some users make a habit of
checking the database with R:SCOPE before
rebuilding the database, or before making a backup of
the files.
We do not see many cases in this regard. But, it
was more prevalent in the past, whether it be
linked to older networks or older versions, which is why R:SCOPE was created.
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!
--
--- RBASE-L
=======================3D=======================3
D=
TO POST A MESSAGE TO ALL MEMBERS:
Send a plain text email to [email protected]
(Don't use any of these words as your Subject:
INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH,
REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP)
=======================3D=======================3
D=
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: INTRO
=======================3D=======================3
D=
TO UNSUBSCRIBE:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: UNSUBSCRIBE
=======================3D=======================3
D=
TO SEARCH ARCHIVES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: SEARCH-n
(where n is the number of days). In the message body,
place any
text to search for.
=======================3D=======================3
D=
