Bis Sync Operation and Issues

A BIS syncronise is an operation of aligning remote databases to a server database, ensuring that all updates have been applied. Most updates are dynamically sent and received during normal operation, however circumstances can arise where systems are offline and might miss updates, or errors occur at either end processing updates. A syncronise is therefore performed to ensure the integrity of all data.

Steps in a syncronise are:

1. Set a flag internally to record that a BIS syncronise is in progress
2. Connect to the server and negotiate communication
3. Scan for sales that have not yet been confirmed as stored permanently and transmit these to server.
4. Request data that is to be downloaded, such as products, and load changes to the tables are required.
5. Send all audit style data that has not been confirmed by the server
6. Process any confirmation messages from the server
7. Finally, regardless of success of failure status, reset the internal "Sync in Progress" flag to no.

Startup Warning

During startup, the POS system checks the sync in progress flag to see if a syncronise was in operation when the previous POS was terminated. If this flag is set, the following message is displayed

The last BIS syncronise transfer did NOT complete correctly. The system may not have all the information required to operate correctly. You should perform a syncronise operation soon.

If you receive this message, you should perform a manual syncronise operation as soon as possible. The system might not have all products and pricing and you cannot call support for "missing data" style of problems until after you have successfully syncronised.

Causes of this did not complete message are:

• The user started a syncronise and exited the POS application while still processing
• The computer was powered off while POS syncronise in progress.
• The POS crashed while sync was in progress.
• The network connection to the server failed during the sync operation
• You are running foreground and background POS instances (ie a foreground and service) on the same machine and background is still operating when foreground started.
• You have shared database setup and have two lanes using the same lane numbers (lane numbers cannot be shared)

This message is not directly caused by reported errors, it only comes from process termination. To isolate these problems you need to check the status of the previous transaction - check bistfr.htm (although this won't help too much), check crash.out to see if system crashed, review Windows Event Viewer to see if machine was closed. Ask user if they exited POS while running.

This error is occasionally reported as it is a generic catchall type message for many sub problems. If a site is reporting this frequently, then the underlying cause should be isolated. If contacting Fieldpine Support, one of the key requirements is for us to either see the problem fail first hand, or obtain a complete POS backup taken as soon as the problem is detected.

Performance

The performance of the syncronise operation is directly related to volume of data and how often you syncronise. If you syncronise weekly, then it will be much slower than daily. As a rule of thumb, if you are syncronising daily and they are completing correctly, then it should not take more than 10 minutes maximum, with typical times more around 1 minute. Syncronise operations are affected greatly by many external factors, so performance can vary from day to day.

• Ensure all indexes are present. Use the major index check quickcode to verify (71242) all indexes are present
• If using Access databases, ensure they have been compressed recently.
• Verify network connectivity and performance, use ping with large packet sizes. Networks must show 0% packet loss for optimum performance
• Ensure indexes are present on the server.
• When a sale (etc) is received on the server, it must scan the master database to check if already loaded. This information is cached, but the first user will take a performance hit
• Ensure that tables do not have illegal datatypes or user columns that are incorrectly named (User columns in the database must start with the letter "u")

Problems

The following are known to lead to issues in some older versions of POS with syncronise, most of these are corrected in more recent releases

• Customers entries require a name. Sites that directly load the database must ensure the "name" field for customers has at least one character.
• Product entries require a description and shortname of at least one character each.
• If sync operations frquently hang after sending a small number of bytes, but work on 2nd attempt, this is highlighting a problem with network connectivity. Specifically, the TCP link has been created but the first packet of data does not reach the server and no errors are returned. More recent versions of POS attempt to detect and workaround this problem.

THIS ARTICLE APPLIES TO

• Fieldpine POSGreen. As at July 2014