Hi All,
I appear to have found an obscure bug in the VERIFY CURRENT DATA FILE
command. This info here in the hope that this might save someone else
some time further down the track...
Summary
If the VERIFY CURRENT DATA FILE command is called from a stored
procedure on a server, AND if some externally stored data is NOT in the
correct place (i.e. ABC.ExternalData folder), then the command 'hangs'
and the server becomes inoperable, eventually needing to be force quit.
This is despite the fact that when manually using the 'Verify Records
and Indexes' button on the Maintenance page of the Server Admin window,
the verification process completes perfectly fine and does NOT exhibit
the same behaviour.
This has been established using a built server with 4D v17R4, running on
a Windows Server 2019 (Std) machine. It has been experienced in all R
versions of v17, and possibly v16 as well (but I can't recall exactly
when it started happening).
More Details
Our example database has a table with a Picture field that is set to be
'Stored outside data file'.
We have an overnight process running that calls VERIFY CURRENT DATA FILE
in the middle of the night to check the status of the datafile and to
report if it picks up any errors.
VERIFY CURRENT DATA FILE(Verify all;Timestamp log file
name;"Datafile_Verification_Callback")
The 'Datafile_Verification_Callback' method simply tracks the number of
errors found and displays a small MESSAGE window on screen during the
process so that an admin looking at the server can tell that the process
is running (and how far through it is to completion).
When running on the Live server this causes no problems, and has run
fine for several years.
However we have a local test server in our office and periodically grab
a fresh copy of the live datafile. Due to the size of the datafile
(>100Gb), the IT manager does not always provide the xyx.ExternalData
folder, which for most intents and purposes of this test machine is OK.
It's only a small amount of data and we'd obviously grab the folder if
we were testing that area of the system.
Periodically the test server is left turned on overnight, and for some
time we have realised that when this happens, the overnight verification
process has automatically run, and in all cases has 'hung' the test
server application, requiring a force start.
We've recently tracked this down to being when the table with the
external picture data was being checked. So we updated the
xyx.ExternalData folder on the test machine and found that VERIFY
CURRENT DATA FILE still crashed. We then created a routine to double
check the external data, and to delete any records that were 'corrupt',
i.e.:
$DataPath:=Get external data path([Driver_Pictures]Pictures
If (Test path name($DataPath)#Is a document)
DELETE RECORD([Driver_Pictures])
End if
This was simply due to the fact that we did NOT use both the latest
datafile, and the latest xyx.ExternalData folder -- meaning that there
were some records in the datafile which did not have the appropriate
corresponding data in the xyx.ExternalData folder.
Having done this we were left with several thousand records in the
datafile, which all had matching data in the xyx.ExternalData folder.
Once we did this and ran the VERIFY CURRENT DATA FILE command again, the
verification process completed and terminated correctly.
Obviously this is an extreme edge case, and we know in theory we should
NOT be using the datafile with the the appropriate xyx.ExternalData
folder, yada yada yada! ;-)
However I guess the point is that there appears to be a discrepancy
between the behaviour of the VERIFY CURRENT DATA FILE command and the
manual 'Verify Records and Indexes' button on the Maintenance page of
the Server Admin window. This is not going to affect many people
(any?), but certainly in my case if the two verification options behaved
the same way, then it's likely that I would have spent much less time
trying to track down why the test server was hanging in the middle of
the night, and worrying about why it was and why the live server wasn't ....
Cheers,
Allan Udy
Golden Micro Solutions Ltd, Blenheim, New Zealand
http://www.golden.co.nz<http://www.golden.co.nz>
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
