Comparing XUD Sites
If log files are not processed correctly, or there has been a system failure work is not transferred correctly between sites. This can lead to records being different on the remote machine(s). There are options with Premvet to allow you to identify these and correct them.
We would recommend to compare sites on a monthly basis.
This is a three step process,
- Extract the data
- Let the machines talk
- Run the report.
Extract the data
This step will create a 'snapshot' of the sites database and send it over to the master machine.
- Manually - use Xmenu options:
- -> a) Utilities
- -> j) Compare data with remote sites
- -> a) Run xud program
This must be run on all machines, it will startup a program that quickly extracts the client name and current balance to a file.
Note: If you connected via the modem to the remote site you do NOT need to stay on-line till the program has finished.
- Automatically - if you want to generate this list on a regular basis
add an entry to crontab such as
10 4 25 * * /usr/local/bin/vet -p xud
(This will run on the 25th of every month at 4:10 am)
Let the machines talk
The file generated by the above option will be transferred over to the main machine the next time the send utility (x_send) is run. It will become visible when the checking program (x_check) runs on the main system.
You can check if all the files have transferred by using xmenu option:
- -> a) Utilities
- -> j) Compare data with remote sites
- -> b) View current xud files.
This will list the available files, called xud.site-number e.g. branch 1 will be xud.1, branch 3 will be xud.3. Included in the list will be the date the file was received on the local machine and the date the run took place.
You should be able to tell from that listing if all the files are current and available for the next step. If not, either wait a bit longer or force a transfer of data.
Compare the data.
Again via xmenu option:
- -> a) Utilities
- -> j) Compare data with remote sites
- -> c) Check for balances or
-> d) Check addresses
Each option should be self explanatory. You will be asked if you want to send the results to the screen or printer (Unix default printer only).
Note: The program has to store all the data in memory while it does the comparison, this will not be a problem for most of you, you should be aware, on low memory machines it may take a while.
The system will only show records where there is a difference. Where differences are found a new option within the vet system can be used to make corrections (see below).
Remember the records are current when the snapshot was taken. Work added
since or work 'in transit' will not be included. You should ignore any
records that have a last paid or last consultation date just prior
to the snapshot.
Bouncing Work
If from the procedure above you have determined that some records are wrong and need to be sent out. You have the option to 'bounce' the records - this will send the FULL management and clinical records to all sites. This will overwrite the corresponding client details on all remote machines.
This option is found on:
New Menu Style: System Management; Cross Updating; Bounce Work
You will be asked to specify the client number to send and it will be sent.
Notes:
| Vatbook: | No check is made on the remote machines to see if existing
work on the card about to be overwritten is in the current
vatbook. If so, then it will not be processed.
The new work that has been sent from one of the sites will not go through the vatbook.
|
|---|---|
| File Size: | On the remote surgeries, the existing clinical work will be marked as free before the new records are added. This can lead to, over a period of time, a fair number of records on the clinical free list. You should, periodically, run the validation option 'Re-organise files'. This will compact the clinical files, re-using all the free records. |