Home > Technical > System Admin > Technical

System Admin Technical

 Databases

A database is basically a collection of data. This data is generally divided into tables, where all the data in a table is of the same type, for example ITEMS.

 File Formats

 INI Files

There are a number of INI files used by the system. These are generally stored in the Windows directory.

DRSPLASH.INI

This file contains details about the images to be used for the splash screens when loading programs. Below is a sample file:

[Bitmaps]

DefaultBitMap=c:\drsapps\bmps\Splash256.bmp

DRSPOSSYSTEM.INI

This file is used by DynaPOS and contains various POS related settings. It is created by DynaPOS each time a data reload is done.

DRSSCHEME.INI

This file controls the look and feel of the system. It contains details of colour schemes and the look of buttons. See Look and Feel Issues for more details.

DYNAMIC.INI

This file contains various environment settings for the user. There is one file per computer. It contains settings like the user's private directory, which will not necessarily be the same on all computers. Shared setting are contained in DRSSYS.INI. The program System Settings is used to modify this file.

SRAPPS.INI

This file is used primarily for recording the size and position of windows when the user exited the program. Next time the user runs the program, the system will set the windows back to the same size and position. These settings are stored in a separate section for each window. The section name is the caption of the window. Some programs also use this file to record selection details so that these can be used as default values next time the program is run.

 Loading Statistics

 Look And Feel Issues

The graphical look and feel of the programs is controlled by the DRSSCHEME.INI file, an extract of which is shown below. Each user can have their own copy of DRSSCHEME.INI or a centralised file can be used. A centralised file will reduce administration if changes are required to the file. If a centralised file is used, store it on the server in a directory accessible to all users. Set the Scheme INI setting in System Settings to the directory and name of this file, for example s:\drsapps\drsscheme.ini. If this setting is empty, the program will look for DRSSCHEME.INI on the user's computer.

 Modifying Menus

The information displayed on the menu is read from the SRMENU.INI file. The SRMENU.INI can reside on the server to allow centralised administration or each user can have their own copy (usually in their \WINDOWS or \WINNT directory). If a centralised version is used, the Menu INI setting in System Settingsspecifies the name and location of this file. If this setting is empty, the menu program will look for an SRMENU.INI file on the user's computer.

 Replication

Overview

Replication is the means by which data is transferred from one system to another. It allows a head office to send data to its venues, for example new items, cost changes, etc, and for the venue to send its data back, for example sales, purchases, and so on. Because of the size of the system, there is a lot of information which can be replicated.

There are at least two processes involved in replication. The first process sends, or exports, its data. It does this by examining its replication log and producing a text file containing all the data changes. The second process receives, or imports, the text file. Once it is complete, its data will be the same as the first system. One system can be set up to export and import data. For example, a head office would export new item details and import sales. The means by which the text file is transferred from the sender to the receiver is outside the scope of this discussion. There are a number of ways this can be done, for example disk, ftp, e-mail, and it is normally site specific. Again, your software supplier can help you choose the most appropriate option for you.

Data should only be replicated one way otherwise the system will not be sure which version of the data to change. For example, if head office sent Average Cost to the venue, and  the venue also sent its version of Average Cost to head office, which one is correct? Generally one site will be responsible for a given table, for example head office is responsible for items while the venue is responsible for sales. You can have one table being controlled by two sites provided that each site is controlling different fields within the table. The STORERNG table is the best example. Head office will be controlling the cost and sell fields, while the venue will control the stock on hand, average cost and last invoice cost. It is possible for two sites to control one table provided that the primary keys generated by each site are distinct. This is usually done by creating an OffSet number when installing the system.

Setting Up

Directories

The text files used in the replication need to be saved to specific directories. In the Directories tab of System Settings there are two settings Replication and Replication Import. The Replication directory is the root directory where exported files are written to. When exporting files, the system will take this base directory and create a subdirectory for each location that replication files are being exported for. For example, at head office there are two venues which need data, VEN1 and VEN2. Two directories will be created called c:\drsapps\replicationexport\VEN1 and c:\drsapps\replicationexport\VEN2. The export process will write a single file called rep.txt to each of these subdirectories. Each file will contain data specific to the location.

The Replication Import directory is the directory in which the text files will be read from. All files in the directory will be processed in alphabetical order. Each file in the directory must contain a unique name, for example repVEN1.txt and repVEN2.txt. The directory can contain subdirectories, for example one directory per store. In this case all subdirectories will also be processed.

If you are using Replication Service, export files will be generated much more frequently. As a result a conflict might arise with the communications software trying to transfer a file before it is completed. In this case you can setup a temp directory for exporting data. Data will be exported to this directory and when finished, it will be copied to the actual replication export directory. The directory is set in DYNAMIC.INI as follows:

[Directories]

ReplicationTemp=c:\drsapps\replication\temp

Your communications software must be set up to transfer files to and from these directories and rename files as required. For example, for location VEN1, the system must transfer from headoffice c:\drsapps\replicationexport\VEN1\rep.txt to VEN1 c:\drsapps\replicationimport\repVEN1.txt.

Locations

You need to tell the system which locations use this replication method to transfer data. Use Locations to find each location and set the Computer to 'DynaVenue'. If you are at head office and you want to communicate to a multi-location venue, for example a pub, then you only need to change the group location for the venue. The system will automatically include all the locations within the group.

Data

You need to tell the system which data needs to be replicated. Different data will be replicated depending on whether the site is a head office or a venue. Note, that this is the data that is to be exported from one system to another. You do not need to indicate which data is to be imported. All information in the text file will be automatically imported.

Use Replication Maintenance to set up this information. Once this information has been set, the system will log all required data modifications as they occur.

Exporting Data

To export the data, simply run the Replication Export as part of end of day processing. This will look for any logged changes and write them to a text file, one for each replication location. Once completed, all logged changes will be discarded (the log not the actual changes). The text file will be uniquely named as rep.txt.yyyymmddhhnnss, where yyyymmddhhnnss is the current date/time. It is possible to specify a location for the replication process but this should not be done unless directed by your software supplier.

Importing Data

To import replication data, run the Replication Import as part of end of day processing. This will look for any text files and processes them. Once the file is processed it is moved to the back up directory. A report is generated showing the success of the import.

Replication Service

By running the Replication Export and Replication Import as part of your day, you are restricted to getting data back once a day. You can use the Replication Service xxx, to bring back sales more frequently during the day. When the service is running it will import/export data every ten minutes.

There are two options on the Replication tab in System Settings that control the service. These options allow you to specify if the Replication Service imports and/or exports data. This could allow you to import sales regularly at head office but only send price changes as part of end of day.

The Replication Service does the same job as the Replication Export and Replication Import processes. However, the import does not generate a report. Errors are still reported to the audit log.

The File Transfer Service xxx, can be used in conjunction with the Replication Service to transfer files between head office and the stores.

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)