| Classic Menu: | General Application -> Modules -> Cross Updating |
|---|---|
| New Style: | System Management -> Cross Updating |
It contains the following options:
If work is received from the remote site(s) and Background Integration is not being used then this option can be used to process any work.
Note: If there is no work to process then this menu option will not appear.
You may have the situation where one of the record cards at one site is correct, same client branch 2 is missing a payment, and same client branch 3 has a correction. If there are a lot (over 20) records needing bouncing this would suggest a fairly major failure at some point.
We recommend you identify and correct the reason and then transfer the full database via xmenu. See the FAQ Keeping sites up to date for more details.
This option allow you to send the FULL management, clinical records, 'S'heets and Lab (1) screens to all sites. This will overwrite the corresponding client details on all remote machines.
You will be asked to specify the client number to send and it will be added to the log file and will be sent the next time x_send runs.
|
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 work that has been bounced 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. |
This option is similar the bounce work above. However, rather than transfer specific animals, the extract option will check all animals and look for work between specific dates.
The use of this option is for the rare cases where a complete log file is lost/corrupt - You can 're-build' the log file so no work is lost.
You will be asked:
| Client to Start at | Where to start looking |
| Client to End at | Where to end looking |
| Surgery to extract | Which surgery number, or press RETURN for all |
| Start Date | What is the start date |
| Start Time | What is the start time |
| End Date/Time | As the start options except it relates to the end date. |
The system will search for and add the work to the log file, the next time x_send runs it will be sent to the remote sites.
Unlike the bounce option, extract will add to the records on the remote sites. You should ensure you have the dates and times correct otherwise you will end up with duplication.
The system uses the animal number to keep track of the records, as such the animal number must be unique across all sites. Records are allocated from the main sites (this option only appears on the menu at the main site), these are sent out to the branches (in chunks of 200 at a time).
The remote sites then use these records when a new animal is added. Users do NOT need to do anything differently at the branch - the system handles that automatically.
Note: Care should be taken to ensure that the branches have enough blank records for their normal use. You can check this by looking for clients called 'XUD2' for branch 2, 'XUD3' for branch 3 etc.
You can also enter a '?' at the main menu - the entry XUD/DELE Recs: 1637/135 this shows the number of XUD cards for you (the main site will show the total) and the number of Deleted cards - in this case 1637 XUD cards and 135 deleted. If this is used on a remote machine then this is the total for this site. ![]()
You can get the system to automatically allocate records if required. This is done by setting option 7 'Number of XUD sites' (see Parameters Menu in the next chapter) to the number of sites. Whenever x_send runs on the main server the system will check option 8 (Trip/Send if less than) - if there are less than this number of XUD cards the system will automatically create and send the appropriate number of XUD? cards.