Many thanks, Razzak.
I will rebuild all my databases over the next few weeks as I get time to go
through each one first and check for old forms and reports that are no longer
used – often copies made before making changes – and I will check that the
structure is sound and not in need of any alterations. I last did that in
January so a little over halfway through the year is not a bad time to do this
as an addition to my annual rebuild.
I’m sure that you know <g> that I don’t have R:Scope but you did a great job of
selling it. The only reason that I haven’t got it is that R:Base has been so
stable. Even in the past any problems were usually caused by hardware or power
blips. Clearly for business users it is necessary but I’ve always been able to
revert to a backup if need be and re-enter data if I can’t recover it all which
is also rare, thankfully.
Once my databases have been rebuilt I will run Autochk and Reload more often
even than I do now and particularly when making structural changes. I have some
comments displayed at the R:> every time I go to it and I have already added a
reminder there which I will at least see before making any alterations.
I don’t recollect doing anything strange in the ways you suggested and there’s
no network involved. Hopefully the “problem” will disappear after the rebuilds
as suddenly as it arrived.
Again, many thanks for taking the time to help,
Regards,
Alastair.
From: A. Razzak Memon
Sent: Monday, July 22, 2013 8:17 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Autochk query (and an unrelated mysteriousfix)
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!
--
