Manifold Enterprise Edition and higher versions support concurrent, multi-user editing of linked drawings that are created from geometry columns in tables. A drawing can be edited by more than one person at the same time by storing that drawing as a table in a database and then working with it in Manifold as a linked drawing. Each user who needs to edit the drawing can link it into his or her project. It may then be edited by multiple users simultaneously, whether the drawing appears in a drawing window or as a layer in a map window.
For example, a drawing may be linked from an Oracle Spatial database into a project on our machine and we could edit that drawing at the same time that a colleague is also editing it on a different machine. If any editing conflicts arise with other users, say if we delete a particular area while our colleague is moving it to a different location, we can resolve such editing conflicts using the Review pane.
Resolution of editing conflicts is important because when potentially many people are editing the same drawing at the same time it is possible that more than one person might edit the same object (that is, the same point, line or area) differently. Manifold uses a version column in the database table to keep track of which objects have been changed.
If we do not have Enterprise Edition or if we do not create and use a version column, we can still use linked drawings in multi-user environments. However, if no version column is in use then any changes made to objects made by any one user will immediately apply to the data source without notice to other users. Other users will only become aware of such conflicting changes when they refresh their linked drawings and see that someone else's edits have been applied instead of theirs.
Manifold Database Administrator Edition provides the Administrator Console to make it easy to prepare drawings stored on database servers for multi-user editing. Administrator Console allows DBMS administrators to designate friendly names for components, to enable storage of formatting with drawings within the database and to specify defaults to be used when importing and linking drawings, such as automatic use of version columns.
Linked Drawings and Refresh Data
Whenever we edit a linked drawing the objects displayed arise from data fetched from the originating data source to which the drawing is linked. The drawing objects we see and edit are cached locally and will not reflect changes in the originating data source until the drawing is refreshed.
Refreshing a drawing using View - Refresh Data or the equivalent keyboard shortcut ALT F5 re-synchronizes the drawing with the originating data source and updates the Review pane with editing conflicts, if any.
Drawings are refreshed automatically when a project is opened (the default setting in the Tools - Options dialog) but otherwise we can work a long time, if desired, on a drawing without doing a refresh. Whenever we do a refresh, our drawing will be synchronized with the data source so that the drawing contains all of the changes made to the data source (by anyone) since the last refresh, and the data source will be updated with our changes. If our changes conflict with any others, we can resolve them using the Review pane.
For this reason, it is wise to Refresh Data or do an ALT F5 when commencing an editing session and then on a regular basis throughout an editing session.
Multi-User Editing Overview
The following guidelines apply to multi-user editing of drawings linked from enterprise-class DBMS products such as Oracle or SQL Server:
· Drawings linked from geometry data support concurrent multi-user editing. Multi-user editing is not supported with linked images, with linked surfaces or with drawings linked from geocoded tables.
· The table from which the drawing is linked must have a writeable version column that is a numeric column. The version column is normally created by the drawing's author when the drawing is exported into the database. Drawings exported to Oracle spatial data will have a version column created automatically.
· We must specify a column to use as the version column version when we link the drawing into our project if we want to be able to cleanly resolve editing conflicts between users. If we do not specify a version column to use, we can still edit the drawing with multiple users at the same time, but Manifold will not be able to resolve multi-user editing conflicts for us. Therefore, it is wise to always use a version column.
· To enable versioned editing (that is, edits using a version column to resolve conflicts) we must include the drawing's ID column (the default setting) when exporting the drawing into the database. Versioned editing uses the ID column as a key column in the database for faster performance. See the discussion below on key columns.
· Manifold provides two modes to use for resolving editing conflicts. The default mode used when a version column has been specified is to interactively review any editing conflicts with changes made by other users. If a version column has not been specified (or, if we simply choose to be authoritative), we can use an edit mode specifying that any changes made by us will overwrite changes made by others without review. The mode in use may be viewed and specified in the View - Properties - Link / Share Status dialog reached from the View - Properties dialog of the drawing.
· We use the Review pane to see the changes we have made as well as the changes made by other users and to choose which version we prefer to use to resolve any conflict.
· Drawings that have had formatting storage enabled on the database by Administrator Console may be linked with formatting from the server. Any formatting changes made by different users will be automatically managed and resolved by the Review pane.
· Most organizations using Manifold for multiuser editing of linked drawings will install some Database Administrator licenses to enable use of Administrator Console to prepare drawings for fast and easy use by all users and to enable formatting storage within database servers.
Version Columns
To make multi-user editing possible we must have a version column in the table from which the drawing is linked. The version column must be a numeric column and it must be writeable. This column may use any name and does not need literally to be called "version," although it is normally it is given a name similar to that. Most organizations using Manifold extensively will also standardize on using a particular name so that everyone knows that a column of that name is intended for use as the Manifold multi-user editing version column. The version column need not be displayed or linked into the drawing's table: when the drawing is linked from the table we do not have to check this column for inclusion in the drawing's attributes.
If we think that a drawing may be edited by multiple users we normally create a version column in the drawing before exporting it into a database system. If a drawing has already been exported into geometry storage in a database table and does not have a version column, we can easily add a version column to that table. To do so, simply link the table into a Manifold project to create a linked table. Open the linked table and right click onto the column heads to add a new numeric column or use the Table - Design command to add a numeric column. Any numeric data type will be fine for the column: most users will employ the 32-bit integer data type used by default to create numeric columns.
Drawings exported into Oracle spatial databases do not need to have a version column created as this will be done automatically during export into Oracle. The name of the version column so created may be customized, if so desired.
Every time an object is changed by someone, the version value for that object in the version column will change. Manifold can compare the version values for any object as stored in the local cache used for editing with the version value stored in the originating table to tell who has changed that object and if any editing conflicts have arisen. Manifold can then apply the edit mode rule specified by the user (by default, to review conflicts) to resolve any conflicts. Conflicts are viewed and resolved using the Review pane.
Specifying Edit Modes
The method used for resolving editing conflicts between users is specified in the View - Properties - Link / Share Status dialog reached from the View - Properties dialog of the drawing. There are two settings:
· Review changes made by others when resolving conflicts. This mode detects changes made by others to drawing objects and allows us to review editing conflicts using the Review pane. We can then decide whether we prefer our changes or changes made by someone else. This is the default mode whenever we use Enterprise edition or above and have specified a version column. This choice enables orderly, concurrent multi-user editing of geometry in drawings.
· Overwrite changes made by others without review. This mode does not detect changes made in drawing objects by others but simply applies any local changes made, overwriting any changes made by others. This is the only choice if we are not using Enterprise edition or if we have not specified a version column. We can still edit geometry in drawings with this choice, but any changes we make will be immediately applied regardless of what someone else may have done to that same object since our last refresh.
The Edit mode applies to geometry editing only: as is the case with any table attribute editing, any edits of non-geometry fields in a linked drawing's table will always be immediately applied, overwriting any changes made by another user.
Example
In this example we will first export the US_Main sample drawing of the United States into an Oracle 10g Express Edition database. We will then simultaneously edit it by two users from two different sessions of Manifold, deliberately introducing an editing conflict. We will then resolve the conflict using the Review pane.
Step 1: Export a Drawing to Oracle
We begin by creating a project that has the US_Main example drawing in it, as set forth in many of the topics in the Examples chapter. We will export this drawing to an Oracle Express server, so there is no mystery as to what the drawing is or how it got into Oracle.
Note: Depending on the version of US_Main in use the drawing's table may have more than one field as variable length ASCII type. A limitation in Oracle requires us to change the type of such fields (right click on the column header and choose Change type) to a fixed length field of sufficient length to hold the data so that no more than one field is variable length.
We right-click on the drawing in the project pane and choose Export, specifying Data Sources in the Save as type box to launch the Data Source dialog. In the Data Source dialog we create a data source for the Oracle Express server we choose to use. We then double-click that Oracle Express server data source.
In the resulting Export Drawing dialog we choose defaults as seen above.
Note that the Version column box is already filled in for us since Manifold will automatically create a version column when using an Oracle database. Press OK. Close the project.
Step 2: Link a Drawing from the Database
Let us now go to a different machine, launch Manifold and link in the US_Main drawing from the Oracle database.
Since this example will use two different sessions on two different computers to illustrate the resolution of multi-user editing conflicts, we will choose a different color Windows color scheme on each computer. One computer will use the default blue Windows color scheme and the other will use a green color scheme. We will refer to the different computers as the Blue computer and the Green computer.
On the Blue Computer:
We launch Manifold with a new project.
We launch the Database Console and connect to the Oracle server using the Data Source dialog. We highlight the US_Main drawing just exported and press the Link button. The Database Console is almost always used to link drawings from big databases because (unlike the File - Link - Drawing dialog) it has good facilities to make it easy to find the one drawing, possibly among very many items in the database, we would like to use.
The Import / Link Options dialog opens up. We will use the entire drawing (and not just some subset area of interest). Linking a drawing from Oracle will automatically choose the VERSION field in Oracle to use as our version field.
If we open the linked drawing and zoom into the Southeastern portion of the US we see it is indeed the US_Main example drawing in play. Note that we have the Review pane opened and undocked so that it is conveniently near the drawing window when we make screenshots.
On the Green Computer:
Let's now move to the green computer and launch another Manifold session. We can repeat the above procedure to link the same drawing from the same Oracle server into this second session.
If we open the drawing on the second server, we can see that it is also the same, US_Main, drawing. We have also opened the Review pane on the green computer.
On the Blue Computer:
Moving to the blue computer, we CTRL-ALT click on one of the areas (South Carolina) to select it for editing.
We can then SHIFT click and drag one of the editing handles to move the entire state. We will drag South Carolina out into the Atlantic.
We then click on any open space in the drawing to deselect the area from editing.
On the Green Computer:
When we switch over to the green computer, the first thing we notice is that South Carolina has not moved. Manifold won't move objects about in real time as people on different machines edit them, because if Manifold did so it would be impossible to reliably edit drawings in an orderly way. If it did so we could be in the middle of an edit and suddenly the object might be teleported out from under our mouse to a different location.
Instead, Manifold only updates objects when we do a Refresh Data command (or ALT-F5 keyboard shortcut) on the drawing. If we don't Refresh Data on the green computer, the drawing on the green computer will not be refreshed and will not show the changes made on the blue computer. Instead, the drawing will continue to display based upon locally-cached data brought into the green computer from the database to create and display the linked drawing.
In the usual course of events, before we set out to edit an object we would do a quick ALT-F5 to refresh the drawing to see if anyone already has altered an object of interest before we start editing it. However, because we are trying to simulate a situation where two users on two different machines simultaneously edit the same object in different ways, we will not refresh the drawing. Instead we will proceed to edit it.
Because we have not refreshed, the drawing still looks as though no edits have occurred. The Review pane also reports No editing conflicts. We begin by CTRL-ALT clicking on South Carolina to select that area for editing.
We then SHIFT click and drag the state out to the Atlantic again, but this time to a more northerly position.
The moment we release the SHIFT click and drag, South Carolina instantly snaps to the new position, still selected for editing. The moment the area moves, a conflict appears in the Review pane and the pane reports 1 editing conflict.
We can click on the conflict in the Review pane to highlight it. When we do so, Manifold shows us the local edit we have made in blue and the remote edit made by another user in an alarming red color. Colors used for local and remote preview can be set in the Tools - Options dialog; however, the default colors play on the psychology of being easy to remember in that it's natural to assume we are always right and that changes made by other users should be shown in red, "error" color.
Since the same object has been edited in different ways by two different users, we must decide whether to use our local version or to use the remote version. We can choose our local version by pressing the Use Local button.
The conflict disappears from the Review pane and the area we have moved appears without any previews, still selected for editing.
We can click on any open portion of the drawing to deselect the area from editing.
On the Blue Computer:
Back on the blue computer we can see there has been no change in the display.
Until we either do a Refresh Data or attempt a different edit, the drawing will not be updated and no editing conflicts will be indicated by the Review pane.
If we choose Refresh Data or do the ALT-F5 shortcut, the drawing will refresh and the area will move to the position given it on the green computer, as indicated by the red arrow. [Manifold does not actually show red arrows when an object moves as part of the refresh. The red arrow was added to the illustration to show how the object moved.]
Note: The above example assumes Administrator Console has not been used to prepare drawings for simplified linking by setting default properties using the Database Object Properties dialog. When so prepared, drawings may be linked with a simple click of the Link button in Database Console with no need to specify options such as the version column to use.
Disconnected Links and Editing Conflicts
Editing conflicts in a linked drawing are stored locally in the .map project file. If not resolved via the Review pane, they will still be available even if the project is closed and then later opened. This allows deferring resolution of a large number of editing conflicts to a convenient time.
When a project that contains a linked drawing is opened, the linked drawing may or may not be automatically connected to the data source for the drawing. Normally, a linked drawing is automatically connected to its data source when the project is opened as this is the default setting for the Refresh linked components after opening file option in the Tools - Options dialog. However, it is possible that the data source is temporarily unavailable (such as, perhaps, during a network failure) or it is possible that the Refresh linked components after opening file option was turned off for some reason.
If a linked drawing in a project cannot be connected to the data source when the project is opened, any editing conflicts for that linked drawing will be inactive until the drawing is connected to the data source. The Review pane will still report inactive editing conflicts in the total number of conflicts reported in the Review pane's status bar, but inactive conflicts will not appear in the pane's list of editing conflicts. The Review pane will still allow discarding all local changes by using the Use All Remote toolbar button.
Connecting a drawing to the data source by using a Refresh Data or Relink command will refresh conflict data and will make any editing conflicts active again.
When using a data source to create a linked drawing, Manifold will create a signature for that data source which contains a description of the data source's key columns. Manifold can then use the signature to tell if the data source has changed substantially or has been replaced with a similar, but different, data source when a linked drawing is refreshed or relinked. When a linked drawing is refreshed or relinked, Manifold will validate the signature of the data source and will throw away all editing conflicts if the signature has changed, logging a message to that effect in the History pane.
Usage Scenarios
Conflicts created by concurrent multi-user editing can become intricate. For example, just because we pause to review an existing conflict in the Review pane doesn't mean that other people stop working. While we are considering an editing conflict in the Review pane some other person might change the object under review yet again, so that whichever way we decide to resolve the conflict there will still be a conflict with that object that will require a second review.
Example
Editing conflicts are detected by storing the current local version of each drawing object and comparing that version to the version stored in the data source every time the object gets changed. Whenever the local version of the changed object is not the same as the remote version, Manifold records an editing conflict.
There are two users, Andy and Bill, who edit the same linked drawing from different machines. The linked drawing contains two areas, Thing1 and Thing2. The version number for each area starts with 10. Andy launches Manifold and opens a .map project file containing the linked drawing, which refreshes the data for all linked components in the project. Bill does the same.
Andy changes Thing1, which increments its version number to 11. Bill changes Thing2, which increments its version to 11.
Bill now also changes Thing1. This creates an editing conflict, since the local version of Thing1 on Bill's machine is 10 but the remote version of Thing1 is already 11 because Thing1 has already been changed by Andy. If Bill doesn't have the Review pane open, he might not notice the conflict or he might not care, preferring to resolve all editing conflicts later on in his work.
Bill changes Thing2 again, which increments its version to 12. There is no editing conflict, since the local version of Thing2 on Bill's machine was 11 and the remote version of Thing2 was still 11.
Example
There can be situations where the object participating in the editing conflict is being changed while the person reviewing changes to the object decides how to resolve the conflict. In this case, committing local changes to the object will fail to resolve the conflict. Instead, Manifold will fetch the latest remote version of the object from the data source for comparison with local edits, to allow a decision on which version to use based on the latest remote and local changes.
There are two users, Andy and Bill, who edit the same linked drawing from different machines. The linked drawing contains two areas, Thing1 and Thing2. The version number for each area starts with 10. Andy launches Manifold and opens a .map project file containing the linked drawing, which refreshes the data for all linked components in the project. Bill does the same.
Andy changes both Thing1 and Thing2, which increments their versions to 11. Bill changes both Thing1 and Thing2 as well. This created two editing conflicts.
Bill chooses to use his local version of Thing1 in spite of the changes made by Andy. Bill selects Thing1 and presses the Use Local toolbar button. This sends Bill's version of Thing1 to the data source and increments its version to 12.
In the meantime, Andy changes Thing2 one more time, which increments its version to 12 as well. Bill is unaware of that change and reviews the outdated version of Thing2. He chooses to use his local version of Thing2. He selects Thing2 and presses the Use Local toolbar button.
Manifold detects that the version of Thing2, version 11, seen by Bill in the Review pane when he decided to use the local version is not the latest remote version of that object in the data source, version 12. Manifold will not blindly honor the Use Local command issued by Bill without giving Bill a chance to compare his local edits to the latest remote version of Thing2. So instead of applying the Use Local command Manifold will refresh the Review pane on Bill's machine with the latest remote version of the object and will keep the editing conflict open. Bill now has a choice between his local edits and the latest remote version of the object.
As seen in the above example, the Use Local command is not a blind, "crush the remote version no matter what" command. It is a more nuanced command meaning "use my local version if what I see in the Review pane accurately reflects the latest status of the remote version at the time I issue the Use Local command and if not, get the latest remote version and show me the conflict again so I can make up my mind."
Multiuser Editing and Formatting
If we have a Manifold Database Administrator Edition license we can use Administrator Console to enable storage of formatting for drawings in databases. Database Administrator Edition must first be used to enable storage of formatting for a drawing saved in the database. Once storage of formatting is enabled then other Manifold instances, for example, an Enterprise Edition license used by some other user can take advantage of formatting storage in the data source for that drawing. However, if Database Administrator Edition has not been used to configure storage of formatting for a particular drawing in the database, then if we link that drawing into a Manifold project we will not be able to change formatting from the default format settings.
When a drawing saved in a database has had formatting storage for it enabled in the data source, more than one user at a time can link that drawing into a project and change that drawing's formatting. Concurrent multi-user editing of linked drawings that involves changes to formatting by different users is similar to how concurrent, multi-user object editing works:
· Refreshing a linked drawing fetches the latest formatting for that drawing stored in the data source.
· Changing the formatting of a linked drawing uploads those formatting changes back to the data source.
· Editing conflicts when two different users change the formatting in different ways is resolved using the Review pane.
· If the data source becomes unavailable in the process of uploading updated formatting data, the changes are saved in the local component and appear as an editing conflict.
See the View - Panes - Review topic for a visual example of multiuser editing with formatting changes.
Supported Database Systems
Manifold's support for concurrent multi-user editing works with drawings linked from any database in which geometry columns can be stored, so long as that database allows multi-user access and the version column used to keep track of changes in the multiuser environment is writeable. Obviously, if the drawing is being edited the geometry column and any attribute columns involved in the editing must also be writeable.
Versioned editing uses the ID column as a key column in the database for faster performance. Therefore, the database must be able to handle key columns. All modern enterprise-class DBMS products and even most consumer-class DBMS drivers likely to be used with Manifold have this capability.
Although Manifold supports concurrent multi-user editing of drawings linked from a wide range of DBMS products, there is no reason not to use an enterprise-quality DBMS like IBM DB2, Oracle or SQL Server. The Express versions of these database products are free and are vastly superior to consumer-grade free data sources such as Access .mdb. Complete, licensed installations of these three DBMS products are provided on the Manifold DVD.
This example happens to use Oracle, but all three of the major DBMS products are superb, well-engineered software and will work well with Manifold. All three have a host of features with many sophisticated and subtle distinctions in their approach to enterprise DBMS with extensive documentation and far-reaching user communities in their support.
Users tend to have very strong opinions on which DBMS they prefer, opinions so strong that at times they make political or religious controversy seem pallid in comparison. Therefore, other than choosing the "Big 3" as examples for technical support, Manifold does not take sides over which DBMS is the "best." The best one is the one you decide is right for your needs.
If you would like advice in choosing which DBMS to use for your work with Manifold, consider asking the advice of your colleagues in the Manifold Online Community.
Limitations with IBM DB2
IBM DB2 Express-C Edition may be used for Enterprise Edition Enterprise Servers without any technical limitations. However, two small usage limitations apply when DB2 Express-C is used for storing geometry in tables in the database to support subsequent concurrent, multiuser editing. When a drawing is linked from a DB2 Express-C data source the following limitations apply:
· Adding a new object and immediately editing it without refreshing the drawing creates an editing conflict.
· Adding a new object and immediately deleting it without refreshing the drawing will fail.
Therefore, when ever editing drawings linked from a DB2 Express-C data source make sure to refresh the drawing after adding a new object before attempting to edit that object or to delete that object.
Key Columns
Whenever we use a version column to help resolve editing conflicts Manifold must rapidly identify any changes caused by different users within the geometry data in the originating table. That requires high speed access using key relationships supported by the DBMS in which the table is stored. If a data source does not have a key, which can be one column or a combination of columns, versioned editing will not work.
The ID column in any Manifold drawing's table is guaranteed to be unique, since the ID field provides a unique numeric identifier for each object. Exporting drawings to data sources such as Oracle therefore automatically designates the ID column as the key column. This works automatically provided the data source supports key columns and the ID column is included in the list of columns to export.
Virtually all enterprise class DBMS products like IBM DB2, Oracle and SQL Server support key columns, as do many consumer class DBMS products. However, certain database drivers, like those for CSV and DBF files do not support key columns. These formats therefore do not support versioned editing within Manifold System.
Although the ID column will be automatically designated by Manifold on export of a drawing to a data source, if we do not export the ID column or if geometry has been sent to a table (perhaps programmatically or as the result of some manual process other than export) we will have to designate a key column to enable versioned editing. Different DBMS products have different ways of specifying a key column.
If we don't have a key column in such data sources we can still edit the drawing if we do not designate a version column when linking the drawing. In that case the drawing will be fully editable but we will lose the protection of editing conflict resolution given by the version column.
However, failing to have a key field in a data source but designating a version column can have some odd consequences. For example, suppose we link a drawing from an Access .mdb file that stores geometry, that had a version column designated when linking the drawing but which does not have a primary key column in the originating table. In that case we will be able to select items and we will be able to edit attribute values but we will not be able to select an object for editing in the drawing.
The solution to avoiding such oddball situations is to always use a DBMS that supports key columns and to always designate a version column. That's easy enough to do whether we are using consumer grade data sources such as Access .mdb files or have everything done automatically for us with an enterprise-class DBMS like Oracle.
To create a primary key in an .mdb table, link the table into Manifold as a linked table and open the linked table. Choose Table - Design to see and alter the design of the table. Add a new field to be the key field using a default 32-bit integer type. In the Table Design dialog toolbar press in the View Extended Properties mode button. In the Unique column that thus appears for the key field, choose primary key as the value. Press OK.
Tech Tips
Remember, ADO .NET connections are read-only. If we are link a drawing from a DBMS table using ADO.NET, we will not be able to edit the drawing. To link a drawing so it is editable we must use some read/write connection technology such as OLE DB or ODBC or, in the case of Oracle, the automatic use of Oracle's OCI.
Projects may contain many linked drawings, which could be linked from different data sources. The Review pane will show conflicts for whatever drawing window or drawing layer has the focus.
FAQ: Why not Auto-refresh Drawings?
Novice users sometimes wonder why drawings are not refreshed in real time in Manifold, with the drawing objects they contain being changed instantly whenever some other user changes them. That's not done with interactive Manifold sessions to preserve the ability of users to organize their work using conceptually unambiguous beginning and end points to tasks, and to preserve the integrity of data against bizarre modifications caused by the unpredictable overlap of complex editing operations launched by different users at the same time.
Keep in mind that Manifold has profoundly greater editing capabilities than simply moving a dot on a map from one location to another, or simply changing the shape of a line or an area. Manifold operations include commands of awesome complexity and power that can change large numbers of objects at once, dramatically alter the topology of objects or their metrics, create or eliminate objects and so on. Consider, for example, what could happen in a sophisticated Topology Overlay command or a Clip with (Intersect) transform if part-way through the operation a different user changed something about the objects that were being used to "cookie cut" through large numbers of other objects in a different drawing layer. The result could be chaos.
It's true that Manifold could provide extensions to the user interface that equipped such commands with accessory dialogs to deal with the many varieties of chaos that might be induced by such interleaved, real-time edits. But that would greatly complicate the user interface that users would have to learn with a host of special cases and complex dialogs. Instead, the current system provides a simple, clear firewall between changes we make and changes others might make.
In all cases with Manifold, "what you see is what you get." What users see in their linked drawing windows is exactly the local data upon which commands operate. To synchronize our local project with the data source from which the drawing is linked we do a Refresh Data or an ALT F5. Each such refresh brings us up to date and also brings the data source up to date with our changes. If any changes we have made since the last such refresh conflict with edits done by other users, we can see such conflicts in the Review pane and in an orderly way deal with them.
However, in all such cases because the various edits have each in their own projects been "firewalled," so to speak, between refreshes done by their users, each such editing change stands as an organic, coherent whole. When we resolve editing conflicts in the Review pane we can have confidence that whether we pick our local edits or those made by someone else they will be applied to the project in an orderly way, without the chaos of partial combinations between something we did and something someone else did.
Note that in Internet Map Server web sites, we can force a refresh of all linked components on a desired time interval. Such applications are either view-only or permit editing only under the fully-custom control of the application developer. That's a very different situation than the sweeping editing commands available as part of the Manifold user interface.
Advanced users might note there is a philosophical conflict between the rationale described above for avoiding auto-refresh of drawing objects and the immediate propagation back to the data source of changes made in ordinary data attributes in linked tables. That's certainly a breach of perfect philosophical orthogonality, but one rooted in long tradition in multi-user databases. DBMS operators and software vendors have long ago evolved mechanisms for dealing effectively with multi-user attribute editing, which still will be in play in the host DBMS whether an attribute is changed by a Manifold session or some other client of the DBMS server.
It's true that in a GIS environment, where attributes can affect the operation of spatial commands such as the Dissolve command, allowing instant propagation of attribute changes does indeed raise the risk of chaotic interleaved edits of drawing objects. However, even in this case the use of the Review pane will alert users to such conflicts because the object modifications caused by such attribute-dependent commands will result in different objects that will be identified as editing conflicts in object geometry.
See Also
Database Administrator Edition