Category Archives: Case studies

Case study from Control-Bit Technologies

New case study from Control-Bit Technologies!
Control-Bit Technologies is a software manufacturing company that has specialized in the field of computerized security systems since 1985.

Our software has been installed in banks, military bases, high-tech facilities, courts and other places, with many years of successful operation, close personal service and support.  Our products use the most advanced software tools, meeting the customers’ needs and adapting to various kinds of hardware can be achieved quickly and inexpensively.

SESAM is an excellent cost-effective site management software system, which enables easy integration of diverse systems into a simple and intuitive control and reporting command center. SESAM works in Client/Server mode over networks, the intranet, and Internet. SESAM is ideal for industrial complexes, campuses, hotels, shopping centers, correctional, municipal, and other facilities.SESAM is a vendor-independent system that can be easily integrated into previously installed equipment from different vendors. New hardware systems are easily installed with no need to redefine existing applications.

Database and Challanges

We are using Firebird SQL, which is stable, quick, and free (since version 1.5 in 2007, now using version 2.5.2).

Our applications use multiple databases, for various purposes: System configuration database, automatic event logging, photo archiving, and more.

Part of our solutions is to run multi-node hot backups, and remote worker nodes, which requires semi real-time database replication.

A hot backup solution includes a primary server that replicated its databases to the secondary standby server.

Big projects include multiple hot backups, and more that 20 remote worker nodes. The master active server replicates data to all nodes, over LANs and WANs. Some installations are based on slow radio networks, a fact that adds more challenges to achieving a well functioning product which is based on databases.

CopyCat Implementation

We replicate multiple databases to multiple nodes. Some databases are being modified less frequently (system configuration), while others are being updated every second (history logging). Each database has its own record size, update frequency, and network connection speed. We are running multiple processes: one process for each master database. Each replication process has a separate thread per replication node, since some nodes may be off-line, and the network speed to each node is different.

Technical details

  • 10 GB — the size of the history database, old records are automatically cleared
  • 2,000,000 records in history database (limit is only because older history is not required)
  • Approximately 50,000 new records per day (depends on customer application)

Customer Support

During the development and integration of CopyCat into our products, we need technical support. We are impressed by the quick and professional support, including remote session into our computer.

New case study !

A new case study from one of our long-time customers !

 

Our Challenge

Our organization distributes Christian literature through volunteer groups based in two European countries. We needed a central database to keep a record of when, where, and how many pieces of literature were distributed by our multiple groups. This database also had to be accessible by individual members in a manner that was efficient and allowed for various levels of access.

The Solution

To manage the central database, we used MySQL 5.X, with a PHP interface that was developed by CopyCat ; this interface was essential for facilitating safe and encrypted access to the database. For client access, we used Firebird 2.X. Using this framework, and with the support of CopyCat, we were able to accomplish the following:
  1. The central database was accessible by each member of each group on their local computer, even when working offline.
  2. All new data was automatically compiled and updated within the central database.
  3. Each group’s access to the database was restricted, such that a group could change the administrative options for its own geographical region, but not the options for another group’s region.
  4. Within a given group, members who were higher in the administration were allowed greater levels of access to their system.

Conclusion

Given CopyCat’s software and developer support, we were able to design an easy to use, and easy to manage, central database with efficient and flexible client access.