Monitoring & Troubleshooting the
How to Find the Problem
How to Fix the Problem
When everything is configured properly, the
synchronization process should run smoothly in the background
without any need for user intervention.
There are a pair ofreports called Sync Logs you can run after every
cycle is scheduled to be
completed to check for errors and make sure everything was synched
properly. To run
these reports, go to Synchronize>Sync Logs:
This will open a reports window you can use
to preview and print reports.
The Complete Synchronization Log records, for every step of the
: the date, hour, name of the synchronization file, and whether the
(synchronize, upload, or download) was successful. The Synchronization
Log merely shows those synchronization process which were not sucessful
writes in the type of error experinced (e.g. could not access the FTP).
these two reports to monitor ongoing synchronizations.
Over time, there are a number of minor problems that could disrupt the
process: an employee forgets to leave
; there is a power failure at one of the stores; somebody accidentally
a task from the scheduler; the FTP
Server goes down, and so on. Most of the time the problem is not a
and the data will be synched the next time around. Because the system
off of DLMs
, the system "makes up" for lost synchronizations and you are always up
date with the next synchronizaiton--if everything is configured right.
How to Find the Problem
Usually you will find out there is a problem by running one of the
Sync Logs and noticing they report an error. However, on other
ocassions you may suspect
there is an error if a file you were expecing to see (a new Style in
Styles Catalog, a new batch of Invoices for the previous day, etc.)
not show up at the Main or Remotes. If this is the case you need
be able to quickly diagnoses where the problem is and fix it. Follow
1) Make sure there is in fact a problem. For example: perhaps
were expecting more transaction data but there were no further sales
at a store during the period since the last synchronization. Call the
and ask them to find the last Invoice Number in the
Catalog and compare this serial number with the one found at the Main.
can also compare the audit log for a given item at the Remote and at
Main. Any discrepancy will indicate that there is in fact a problem.
if these match up, it probably means that the synchronization was
but there was no new data to transmit.
2) Check the FTP connection. Verify that the Remote in question
still access the Internet (do a sample dial-up if you are using a phone
If possible, check to see if the
synchronization files for recent dates are on the FTP Server
. For example: if you suspect the Main did not receive transaction data
Store #5 from June 7, 2003, then check to see if there is an
or INVOICE00520030607.xtm on the FTP.
If these files are on the FTP Server then you know these files are
created at the Remote and are successfully uploaded. The problem then
at the Main which cannot download and process. If these files are not
the FTP, then the problem is at the Remote. You should also test to make sure the FTP
is configured correctly.
3) Check the Sync Stores Catalog. Verify that the number of
in the Sync
Catalog matches the total number of stores. Make sure there is
still an entry in
the catalog for the store in question and that the "Inactive" checkbox
not been selected.
4) Check the Scheduler. At both the Main and the Remote in
check to make sure that all 8 steps of the synchronization cycle are
into the Scheduler and are
entered in the correct sequence
5) Check the Synchronization Dates. Make sure the document
dates and the catalog synchronization dates match at both the
Main and at the Remotes
. These should be set to the exact same date for every Catalog and
6) Do a Manual Sync. If you still cannot find the problem, go
all eight steps of the synchronization
cycle manually and watch for any error messages.
How to Fix the Problem
Once you've identified the culprit (bad phone line,
scheduler, offline FTP server, etc.) you still need to reconfigure the
to make sure you get all of the data.
Suppose it is now September 16th, 2002 and the problem ocurred between
14- 15th and you are not sure you have all of the data from those days.
likely the date of last synchronization at the Main or Remote is now
to September 16, 2002.
The safest thing to do is to
Set the Catalog Synchronization Date back to September 14th at both
the Main and Remote, and to
Set the Document Synchronization Date back in both places as well.
This way the system will backup and "scoop-up"
all of the data from those dates and you need not worry about
In an extreme case, set the dates back even further or you may even
to resort to Initializing
Catalogs or Regenerating
Copyright © 2004 Dinari Systems LLC