NetDB is a software development environment for creating and managing an integrated distributed network database among many workstations and servers to support development of "Occasionally Connected Smart Client" applications using a data-centric coordination strategy as outlined in the Microsoft patterns and practices document Smart Client Architecture and Design Guide.
Applications built on NetDB architecture have a unique capability to allow the user to operate disconnected from the server when network connection is unavailable while seamlessly integrating into the network database once a network connection is available. When the workstation has a network connection to the server, changes made on the workstation are automatically sent to the central server and updates made by other workstations are sent to the workstation. The transfer of data between the workstation and server is done in background even while the user is operating the application that uses the database.
The schema configuration of all the databases in the network, the forms displayed by the application shell and the printable reports are all controlled by one configuration file which is created and manipulated by the NetDB Configuration Editor. Database field definitions are designed to be application oriented with support for features such as legal value selection, constant table lookup and tables within fields.
The Network Database major components:
- Schema Analyzer maintains schema integrity and constant data definitions between workstations and server.
- Synchronizer insures all workstations and server maintain the current copy of all objects as well as maintain ownership integrity.
The “Schema Analyzer” is not a very visible component of the “Network Database”, but is crucial to ensure the database works consistently across all the machines in the network. This component ensures that the schema definition of the databases on all machines are defined the same and contain any current constant data required by the application. The schema configuration is defined in an XML document that is evaluated by the analyzer and compared with the current schema definition in the database. If there are inconsistencies between the schema definition XML document and the database, the database is adjusted accordingly to reflect the schema definition.
The “Synchronizer” ensures the definition of database objects on the workstation and server match. Since all workstations are running the synchronizer, then a database object that is created or modified on one workstation is synchronized to the server and then synchronized to all active workstations. No synchronization occurs when the workstation is disconnected from the network.
It is important to recognize that database objects and not individual database tables or records are being synchronized. This is necessary to maintain referential integrity in the databases and allow the database to be used on the workstation while synchronization is occurring
The Network Database objects
Database object defined
A database object needs to be consistent within itself so that it can be packed, transferred and then unpack on the destination machine without regards to any other object in the database. This allows the application to be able to use the database on the workstation while the synchronizer is operational. This gives the user the appearance that the database is “alive” such that a database object (such as a Control Data) can be created or modified on one machine and then shortly appear on another machine
The “Synchronizer” works by maintaining the following “System Header” information for each database object:
A database object on two different machines with the same GUID key are consider to be the same if the size, CRC and modification date are the same. The task of the “Synchronizer” is to compare the list of objects on the workstation with the list of objects on the server to make sure the lists on the two machines are consistent. The term “consistent” means either the object attributes are the same or the difference meet the business rules of the specific object. For instance it is possible to restrict the list of Control Data that is transferred to the workstation based on the “Inventory List” of Control Entities (a.k.a. bridge structures,) therefore a Control Data object may not exist on the current workstation because it is not on the inventory list.