Administering Enterprise Servers

Enterprise servers used with Enterprise Edition are based on the host database, so routine administration of Enterprise servers mainly consists of the usual tasks involved in administering the host database. For information on administering your host database (backups and similar tasks) see the documentation provided by your database vendor. This topic discusses issues specific to the interplay of Enterprise servers and saved projects.

 

Checked Out Components

 

The main administrative issue arising when working with Enterprise servers occurs when one user has checked out a component that another user wishes to edit. If one user has checked out a component for editing no other user can edit the component until it is checked back in. If both users are online at the same time the situation is simple to resolve - the user who wants the component emails, instant messages or calls the user who has it checked out and asks that the component be checked back in.

 

Saved Projects and Cached Components

 

A more complex scenario emerges if a user checks out a cached component, saves the project and then the component needs to be used for editing. This situation usually occurs in three forms.

 

§      The same user has checked the component out and saved it in one project file, but needs to edit it in another project file. In this case, the user can open the Server Console and use Undo Check Out to undo the check out. This will show the component as checked in on the server and will abandon any edits to the component that may have been made in the project where it was checked out. This works even in cases where the user cannot remember in which project file the checked out component can be saved.

 

§      One user has checked out a component and saved it in a project file but another user needs to check out the component. In this case, if the user with the checked out component can be located other users must negotiate with him or her to get the needed component checked back in.

 

§      At times users will check out cached components, save them in a project and then become unavailable, perhaps going off on vacation or departing the organization. In such cases a database administrator will have to do a forced rollback of the component check out.

 

Undo Check Out compared to Check In

 

The Undo Check Out command is not the same as a Check In command. When a component is checked out if it is checked in any edits made while it was checked out will be saved to the component. When an Undo Check Out is done, any edits made while it was checked out will be abandoned.

 

Forced Rollbacks

 

Undoing a check out is also called a rollback. Users can undo a check out for components they themselves have checked out by using the Server Console's Undo Check Out command. This command will mark the component as checked in on the server so that the project can update itself the next time it is refreshed. Projects are refreshed whenever:

 

§      The project is opened.

§      The user presses the Refresh button on the project pane toolbar.

§      The refresh timeout interval specified in Tools - Options passes.

 

A more complex situation arises when an administrator must undo a check out for a component when a user who checked out that component is not available to use Undo Check Out in the Server Console. In that case, a manual Undo Check Out must be performed within the Enterprise server's database structure. This is done by manually opening the Enterprise server database and editing fields within the database tables using whatever tool is normally used to make edits to the database.

 

To force a rollback of a component in an Enterprise server:

 

1. Using a suitable tool, connect to the database containing the Enterprise server,

2. Open the mfd_root table,

3. In the mfd_name field, find the names of the components for which check out is to be undone. Each component will be one record.

4. For each such record, change the values of the mfd_user and mfd_user_info fields to either blank strings or NULLs.

5. Commit changes.

 

Very important: Make sure not to edit the system record by accident. This record has "system" in the mfd_type field.

 

Note that the above procedure requires the ability and skill set to be able to open database tables and to edit them. Most DBMS products used as Enterprise servers will have such interactive tools. If a system such as SQL Server Express is used that does not provide interactive tools, one can always link the mfd_root table into a Manifold project using File - Link - Table (OLE DB) and then browse the table and make changes to the mfd_user and mfd_user_info fields in the linked table. Note that OLE DB drivers for most databases do not show a dynamic view of tables: they only show the tables at the moment the connection was made. To see the results of edits, therefore, one must either do a View - Refresh or close the connection and reconnect.

 

Orphaned Check Outs

 

An orphaned check out occurs if a component has been checked out on an Enterprise server without being checked out in a project. This happens in two cases:

 

§      A user checks out a cached component and saves it in a project. Later on the user deletes the project file, either by accident or deliberately (forgetting it contains a saved, checked out component).

§      A user checks out a component while working on a project when a crash occurs before the project can be saved or the component checked in. This might happen during an electrical power failure or other unexpected crash

 

Orphaned check outs are easily resolved by the user launching Manifold, opening the Server Console and issuing an Undo Check Out command for the component. If the user who has an orphaned check out is no longer available, the database administrator can follow the procedure noted above for a forced rollback.

 

Cheap Insurance

 

As with any centralized DBMS, if the Enterprise server database is damaged the data it contains can be lost. It is very important to use a robust DBMS within a robust operating system that is hosted on reliable hardware. The following tips will increase reliability of Enterprise servers:

 

§      Choose a reliable DBMS. Use a real DBMS with reliable transaction capabilities. For example, although Access 2000 is said to work with Enterprise Edition it is a poor choice because of its relatively lower reliability in multi-user environments. Use SQL Server Express instead. It is a free download from Microsoft. SQL Server Express has the full reliability of SQL Server in multi-user environments.

§      Use Windows 7 or Server 2008. Both of these systems are so much more reliable than earlier Windows editions that they should be your only choices for server applications.

§      Choose reliable hardware. Insist on a high quality motherboard for the server and run it conservatively (avoid overclocking processors and other "hot rod" alterations). Consider choosing a motherboard with built-in hardware RAID so that two identical disk drives can be installed for a hardware mirror. If one disk drive fails, the other will enable continued operation until a second drive can be installed.

§      Install service packs and other updates when they are issued by the DBMS vendor and Microsoft. Install the latest service packs for Manifold as well.

§      Install lots of RAM memory. Working with many users in complex DBMS products with small amounts of RAM is a great way to find previously undiscovered bugs in DBMS products.

§      Configure the DBMS for automatic backup to another computer system on the local area network. Systems like SQL Server can be configured to automatically save a backup to a different location.

§      Install an uninterruptable power supply (UPS) to power your server through unexpected electrical power outages and to shut down the server down if the power outage continues past the reserve power of the UPS.

 

Troubleshooting

 

To be sure your Enterprise Edition installation is working correctly, create an Enterprise server using SQL Server Express on the same machine, using an Administrator login for all work. The usual cause of any problems sharing components or otherwise using Enterprise servers are errors in the configuration or operation of the database server, or errors in the configuration or use of access permissions. It's the same familiar story well known to network and database administrators: one can configure a beautiful installation, but if a given user does not have access permissions to use it problems will occur. Ultimately, one cannot administer an Enterprise Edition administration if one does not know how to administer the host Windows operating system as well as the DBMS being used to host the Enterprise server.