Working with Enterprise Edition

Setting aside the creation of Enterprise server databases and the ODBC data sources used to connect to them, working with Manifold System Enterprise Edition is very similar to Manifold System Professional Edition.

 

There are two key dialogs used for interactions with Enterprise servers:

 

·      The Tools - Server Console dialog shows a catalog of components available within a given Enterprise server. Use the Server Console to import or link components from an Enterprise server. The Server Console is also used to organize Enterprise servers by creating folders within the server and arranging components within those folders. Use the Server Console to delete components from the Enterprise server. Removing a component will also remove all maps containing it as a layer.

·      The project pane shows components in the current project just as it does in Manifold System Professional Edition. Right click onto a shared component to Get Latest Version, Check Out, Undo Check Out or Check In an existing remote component or to use Share to upload a component to the Enterprise server.

 

Adding Components to an Enterprise Server

 

To add components to an Enterprise server, right click on a component in the project pane and choose Share. The process is called sharing a component to the server. The component will be uploaded to the Enterprise server and will appear in the project as a shared, read-only component. Sharing a component will share all dependent components as well. For example, if we share a map to an Enterprise server all of the components that are layers in the map will also be shared to that server.

 

When sharing a component to the server the component is uploaded to the Enterprise server in compressed form, growing the storage requirements of the Enterprise server by the compressed size of the component. Compression achieved by Enterprise servers will vary depending on the component with typical compression factors achieved being those similar to compression achieved by "zip" utilities, the same as if the components were saved in a compressed .map project file.

 

Sharing a subsidiary component to an Enterprise server will also share the parent component to the Enterprise server. For example, sharing a terrain or a profile will also share the terrain's or the profile's parent surface as well. Sharing an elevation will also share the elevation's profile and the profile's surface as well.

 

Removing Components from an Enterprise Server

 

Use the Server Console to remove components from an Enterprise server. Click on a component to highlight it and then press the Remove button. We cannot remove a component that is checked out. If a component is linked into a project removing it from the server will also remove it from the project.

 

Removing a component from the server will remove all components in our project that are bound to that component. For example, removing a map from the server will remove the map, but will leave components that were constituent layers of the map (the map depends on the layers but not vice versa). On the other hand, removing a component will remove any map from the server that contains that component as a layer. Removing a drawing will also remove the drawing's table and vice versa because a drawing and the drawing's table are inextricably bound to each other.

 

Getting Shared Components

 

Components may be imported from any of the file formats supported by Manifold. They may also be imported or linked from an Enterprise server by using either the File - Import or File - Link commands or via the Tools - Server Console dialog.

 

When a remote component is linked into the current project it appears in the project pane with a "lock" icon to show it is a shared component that is read-only. If it is opened, it may be viewed or participate in a map but it cannot be modified in any way. If we open it in a window the format toolbar, the selection toolbar and other editing toolbars will not be enabled.

 

Modifying a Shared Component

 

To modify a shared component we right click on it and choose Check Out. When a component is checked out it may be modified. All toolbars will be enabled for that component. As long as we have a component checked out from an Enterprise server, no other user can check out that component. Another user can get it by linking it into their project, but they cannot check it out to make modifications until we check it back into the server. When done modifying a component we should right click on it and Check In. This will upload the changes to the server and make the component a read-only shared component.

 

If we would like to abandon any modifications made, we right click on a component and choose Undo Check Out. This abandons any changes and gets the latest version of the component from the server. Checked out components cannot be deleted from a project pane. To delete a checked out component, either check it in or undo the check out and then delete it.

 

Manifold tries to provide the greatest range of modifications possible in a component without checking out dependent components. This adds flexibility at the cost of requiring some additional thought. For example, if we check out a drawing we will be able to format that drawing but we will not be able to add new objects (points, lines, areas) unless we also check out the drawing's table.

 

Note that if another user has already checked out a component that we wish to modify we will not be able to Check Out the component. We will have to wait until that other user has checked it back in.

 

When exiting Manifold or closing a project, the system will remind us if we have any shared components that are still checked out. It is possible to close Manifold while a component is still checked out. We may want to keep a component checked out until the next time we are able to work with Manifold because we have not yet finished modifying it.

 

Getting Changes

 

If someone else checks out a shared component we will not see any modifications they make until they check it in and we choose Get Latest Version. This will update the component in our project with the latest version from the Enterprise server.

 

Working with Maps

 

Maps may be shared to an Enterprise server subject to the following conditions:

 

·      A shared map can only contain layers from the same Enterprise server on which it is shared.

·      Adding an existing layer to a shared map requires that the existing layer a) is shared on the same Enterprise server with the map and b) is checked out.

 

Important: components not fulfilling the above criteria are not shown in the Add Existing Layer dialog and will refuse to drop into a map when dragged from the Project pane.

 

·      Removing existing layers from a shared map does not require anything except that the map itself must be checked out,

·      Adding new layers to a shared map is not allowed.

·      Local maps can contain both local components and shared components (possibly from different servers).

·      Removing a shared drawing, image, labels or surface component from a project will remove all shared maps containing it as a layer.

 

Sharing Linked Images

 

Sharing a linked image to an Enterprise server places the linking information into the Enterprise server and not the actual image data. Importing or linking such a shared linked image to alocal project will re-establish the connection to the relevant file or server. See the Linked Images topic.

 

Miscellaneous Dependencies

 

Because shared components are usually read-only, numerous dependencies arise between components that are related to other components. Non-trivial dependencies that will become apparent as a result of automatic disabling of menus and toolbar buttons include:

 

·      Adding or removing objects in a shared drawing requires checking out both the drawing and the table bound to the drawing (which is also shared). Since most drawing transforms either create or remove objects, they also require checking out both the drawing and the drawing's table. Editing objects in a shared drawing using visual editing tools (so long as objects are modified but not added or removed) requires checking out the drawing, but not the table.

·      The Transfer Selection dialog does not allow transferring a selection to shared components that have not been checked out.

·      Removing records from a table bound to a shared drawing (hence also shared) is similar to removing objects from that drawing and requires checking out both the table and the drawing it is bound to.

·      Removing a table column used in drawing formatting (assuming both the drawing and the table are shared) requires checking out both table and drawing.

·      Adding a relation to a shared table can only go to a table shared on the same Enterprise server and requires checking out both tables. The Add Relation dialog launched on a shared table hides local tables and tables shared on other Enterprise servers. The Add Relation dialog launched on a local table hides all shared tables.

·      Shared components cannot be renamed.

·      To preserve naming consistency, remote components cannot be linked into a project if they have the same name as a local component already in the project. Likewise, a local component cannot be shared to an Enterprise server if the server already has a remote component of the same name. Rename components as necessary to make room for like-named components that are to be linked or shared.

·      A shared map does not allow dragging layer tabs to new positions unless it is checked out.

·      Unsharing a component that "owns" other component unshares all owned components. For example, unsharing a drawing also unshares its table, any scripts bound to the table and any labels bound to the drawing. Similarly, unsharing a component that "is referred to" by other components unshares all referring components. For example, unsharing a drawing also unshares any maps containing the drawing as a layer, any tables linked to the drawing's table with relations, any components owned by such tables (such as scripts) and so on.

 

Relations and Shared Tables

 

For advanced users, it may be useful to consider how relations between shared tables can and cannot be formed.

 

Manifold can establish a relation between an ordinary table and a linked table, between two linked tables, between two shared tables located on the same Enterprise server, but not between an ordinary table and a shared table, or between two shared tables located on different Enterprise servers.

 

Let's do a thought experiment to consider what could happen if a relation between an ordinary table and a shared table were allowed. Suppose we check out a shared table, create a relation between this shared table and an ordinary table, bring some columns from the ordinary table into the shared table, and then check in the shared table. We then go to another machine and bring the shared table into a new project. On the new machine Manifold will not be able to display the data in the columns brought in from the ordinary table we used on the first machine, since that table is not in the project we created on the second machine.

 

Even if the project on the second machine happens to contain a table with the same name as the ordinary table on the first machine, there is no guarantee that the shared table will display the same data on the first and second machines. To guard against situations like this we cannot form a relation between an ordinary table and a shared table.

 

If it was possible to create a relation between two shared tables located on different Enterprise servers we could encounter similar problems. If this were allowed there would be nothing stopping us from linking to the first table, but not to the second table, and creating a situation where the first table would not have any way to display data from the second table. Note that this is different from the case where both tables are on the same Enterprise server, since in that case the system will automatically link in the second table if we attempt to link to the first table.

 

Saving Projects - Cached Components

 

Enterprise projects are saved in the usual way. Components may be saved as cached or as uncached components. When the project is opened again the links to the Enterprise server will be automatically re-established if the project is opened on the same system, where the same connection string to the ODBC data source representing the Enterprise server can work. See the Cached and Uncached Components topic for additional information.

 

When saving a project that contains a cached checked out component, that component will remain checked out until that project is opened again and the component checked in. To see how this works, check out a component and then save the project and close Manifold. Launch Manifold again and link the component from the Enterprise server into the new project. It will be reported as checked out by some other user because it is still checked out in the previous project that was saved.

 

This is good, because it allows people to take breaks while reserving the component and their current work state by leaving it checked out. In fact, one can check out a component and save the project and then open a second project and link the component from the server into that second project. In the saved project the component is checked out. In the new, open project the component is shown as checked out by another user.

 

This, too, is sensible because we may be working with the same component in several different projects at the same time. We might be in the middle of editing it in one project yet have to set aside our work temporarily to work on a different project that also uses that component. When we set aside our editing session we can save the project with the component in a checked out state. When we open another project that also uses that component it will appear in the project as checked out by another user. The component will be seen in the project pane with a dark lock icon, the usual icon showing it is checked out by a different user (the tool tip info will show it is checked out by us).

 

When we open the Server Console it will show components that are checked out by us in different projects with a red link icon. This is to remind us that we have some components checked out in projects other than the one on which we are currently working.

 

It could well be that we check out a component, save the project, set aside our work and then later forget we have saved the project with a checked out component. It might happen that when we see the red link icon for a component in the Server Console we won't remember in which project .map file it has been saved in a checked out state, or even whether or not we have deleted the .map file in which it was saved in a checked out state. At such times we can use the Undo Check Out button in the Server Console to undo the check out status of that component. This command will reset the state of the component on the Enterprise server to checked in. The next time the project containing the component in a checked out state is opened or refreshed, Manifold will automatically execute an Undo Check Out on that component in the project state and will cause any changes made since the last check in to be discarded.

 

Users with experience participating in large teams will predict that some users may check out a component and then depart for vacation or otherwise instill a desire in Administrators to forcibly rollback a checkout for a component that the server shows is checked out in someone's project. Undoing check outs made by users other than the current user is unsafe and should be done only by the DB administrator. See the Administering Enterprise Servers topic for notes on forced rollback (undo check out) of components checked out by someone else.

 

Note that we cannot Close a project if it contains checked out components that have been checked out since the last save.

 

Saving Projects - Uncached Components

 

Saving projects that contain uncached components is the same as saving projects with cached components, except that in the case of uncached components we cannot save a project that contains checked out components. The reason is simple: since an uncached component is always reloaded from the Enterprise server when a project is opened, it makes no sense to save a partially edited version that will be replaced the moment the project is reopened. Likewise, one cannot Close a project that contains a checked out, uncached component.

 

Capacity

 

Enterprise projects are limited to a maximum of 2 gigabytes of components in uncompressed form. There is no limit to the number of components that may be saved on the Enterprise server except for whatever capacity limitations are imposed by the database provider used to host the Enterprise server.

 

Security

 

User access permissions in Enterprise Edition are set by the user access permissions applicable to the database that hosts the Enterprise server. Most database management systems, such as SQL Server, have numerous options for database security in combination with the operating system security model as well as various hierarchical rules controlling propagation of permissions between different database objects. It is therefore essential to understand thoroughly the Windows security model as well as the security model used by the database system.

 

Project Pane Updates

 

By default, Manifold will contact the Enterprise server every 120 seconds to see if any shared components have been checked out or checked back in by another user, updating the status icons in the project pane accordingly. This automatic refresh may be disabled in Tools - Options - Server Storage by unchecking the Refresh state of shared components box. The refresh time may also be set to a value different than 120 seconds.

 

Tech Tip

 

We would often like to save comments with a shared component on the Enterprise server so that whenever someone gets the component they will automatically get our comments with it. This can be done by saving any notes desired into the Description box of a component's Properties dialog.

 

Notes

 

Why must an existing layer be checked out if it is to be added to a shared map? The existing layer must be checked out to protect against the following scenario:

 

§      An Enterprise server contains map M and drawings D1, D2 and D3. Drawings D1 and D2 are layers of M and all components are checked-in.

§      User U1 check outs M and adds D3 to the map,

§      User U2 deletes D3 from the server,

§      User U1 checks in M, which is now invalid.