A point of sales system handles, broadly speaking, two kinds of data:

1. Data needed by the system to run itself.

This includes and is not limited to: a table of all the products to be scanned, a list all members, a list of all cashiers authorized to use the system, a list of all possible tenders, a key to the numbers on manufacturer coupons, and so on. I call this kind of data "operational data".

Master copies of operational data tables are kept in a database called "is4c_op" on the server. These table need to be kept up to date either by data entry or some form of electronic transfer via integrated, or even automated, processes. The maintenance of operational data on the server constitutes what I call "back end maintenance".

Besides the main server, each lane is a MySQL data server in it's own right. Operational data tables are periodically "pushed" from the server to the lane and are cached in a database called "opdata". Data in opdata is not edited except via synchronization with the server.

The lane is considered mission critical. When the server goes down, it causes uproar in the back among the I.T. people and the department heads, but the store plows on. If the lanes go down, however, no business can be conducted. The doors shut and the "closed" sign comes up. Even minor malfunctions on the lanes can bring things to a standstill. With IS4C, the lane is considered more important than the server. We keep the lane running no matter what, and one way to bring down a lane, as we have found out, is to have corrupted data in opdata. We have learned to put a safeguard in place in the form of a buffer database on the lane called "is4c_op". When synchronizing data across the network with the server, data is first put into is4c_op. The new data in is4c_op is checked for possible corruption first before old data in opdata is replaced.

The lane therefore has two databases to deal with operational data: opdata, and a synchronization buffer, is4c_op.

2. Data generated by the lane.

Every time an input peripheral is used in the course of a sales transaction, as with the pressing of a key, the passing of a barcode label across the scanner, records are written into tables on the lane. The cumulation of this data input constitutes the raw sales record for the lane. At the end of each transaction, sales records for the transaction are uploaded to the server. The cumulation of all sales records from all lanes in is4c_log, in turn, constitutes the complete sales data for the entire store. The table that holds the cumulated sales records is often referred to as the "transaction log", or sometimes, "t-log". All reporting and analysis involving sales in the organization involves the t-log and it is easily the most import set of data in the whole system. Having a conveniently accessible t-log in an open architecture system is probably one of the reasons why you are interested in IS4C. The mining of the t-log on the server to generate reports constitutes what I call "back end reporting".

Sales records are first generated at the lane, where the input devices are. They are entered into tables in a database called "translog". translog acts as a buffer for sales data before they are written to the server. It also serves as an archive, because whenever transaction records are uploaded to the server, copies are also saved on the lane. When the server goes down - not that Linux servers ever go down - sales records accumulate on the lane until such time when the server is available again. And if the server should vanish altogether, the master t-log can be reconstructed by combining all the transaction logs from all the lanes.

The lane therefore has one database to deal with sales data: translog.

In addition, for the purpose of testing to see if everything works, we set up a database is4c_log on the lane, so that when we first set up a lane, it can point to itself as the server.

To recap, the lane hosts four databases: is4c_op, opdata, translog and is4c_log. is4c_op is a buffer and is4c_log is only there for testing. The main idea is, the system operates by reading from opdata, and writing to translog.

To install these databases, with all the elements, plus demo data, run the script
/pos/installation/lane_db-install

The script will ask you for the mysql path, user name, and password. If you are not sure, use the default.

If you don't see any error messages, then that's it. If there are error messages, the system won't run correctly. In that case, drop us an email at is4c@wedge.coop or report to the forum, and we'll try to sort it out.

Now let's see if PHP is able to work correctly with MySQL