-
-
-
- The plugin shows up the export window but automatically starts the export to the first database declared in the database list (one may use the up and down arrows to order your databases in the list). -
- The plugin shows up the export window and waits for the user to click on the "Export" button. -
-
-
- When the import/export is successful, the import window/export window is automatically closed -
- Even if the import/export is successful, the user needs to click on the "close" button in order to close the window. -
-
-
- A zero in shown in cases when no component is imported/exported. -
- Cases are left emptywhen no component is imported/exported. -
-
-
- As the plugin requires memory to work, it can check that Archi is ran with enough memory when it is initialized (at least 1 GB). -
- The plugin won't check for the available memory during its initialization. -
-
-
- After a successful export, the model's dirty flag is removed so the model will be considered as saved by Archi (Archi will not ask to save the model to an Archimate file when it is closed). -
- The model's dirty flag is not removed, even after a successful export, so a popup will be displayed when Archi is closed, asking to save the model to an Archimate file. -
- Compare model to the database before export
-
-
- The plugin compares the model components to the database content and shows up the result in the export window. This slows down a bit the export process but the user knows what the export process will do in the database. -
- The plugin does not compare the model to the database until the user clicks on the "Export". This quicks up a bit the export process, but the user does not know in advance what the plugin will do in the database before he clicks on the "Export" button. -
- - Keep partially imported model in case of error
-
-
- In case of an error during the import of a model, the plugin keeps the partially imported model. Please note that this option is for debugging purpose, you must never export back a partially imported model, else you will corrupt your model in the database. Use this option at your own risks. -
- The plugin does not keep in memory any partially imported model (highly recommended). -
- - Show debugging information in context menu
-
-
- Adds a context menu entry that leads to debugging information (ID, version, checksum, database status, ...). -
- The debug context menu entry will be hidden. -
- - Append suffix when import component in copy mode
-
-
- It is possible to change the suffix that is added to components' name when the are imported in copy mode from the database. -
-
-
Online help
-All the database plugin windows have got a
button that shows up these help pages.
-- -
Logger
-The logger tab allows to specify a log file and the level of information to store in this log file. -Disabled
-When disabled, the logger does not generate any log nor error message. --
Simple mode
-
-In simple mode, one should only specify the level of information and a filename (on Windows, it is not necessary to double the backslashes).
-
-Please note that enabling debug or, even more, trace level has got an impact on the plugin performances. You may activate it only if required. -
-
Expert mode
-
-In expert mode, you are provided with a simple text editor and you may configure the Log4j logger manually (on Windows, it is necessary to double the backslashes).
-
-This mode is very powerful, as you may specify several log files, with different level of information. You may also change the lines format.
-
-This option must be reserved to people who have knowledge about Log4j as a bad configuration can stop the plugin from working correctly. In all cases, it is always possible to restore a safe and working configuration using the "Restore defaults" button. - - \ No newline at end of file + + + + +
Configure the plugin
++
The plugin can be configured through a preference page that can be accessed using Archi's Edit / Preferences menu:
+
+
+
+
If the plugin has been successfully installed, a new Database plugin entry appears in Archi's preferences window:
+
+
The database plugin preferences are organized in 3 tabs:
+-
+
- Behaviour +
- Options +
- Logger +
Behaviour tab
+The behaviour tab is the default tab that is displayed when accessing the database plugin preferences:
+
+
Version
+This box shows up the actual plugin's version:
+
+ In addition, the Check for update button allows to manually check if you've got the latest version of the plugin:
+
+ Should a new version is found on Github, the plugin asks if it may be downloaded and installed:
+
The Check release note button allows to open a web explorer and show the plugin release notes from Github (https://github.com/archi-contribs/database-plugin/blob/master/v2/release_note%20versions%204.9.md).
+The Yes button downloads the latest version of the plugin from GitHub and install it to Archi, as if it was installed manually following Archi plugin installation mechanism.
+While the plugin is downloaded, he following popup window is displayed:
+
Once the latest version is downloaded and installed, Archi needs to be restarted to switch between the old plugin version to the new version. You may postpone Archi restart, but the new plugin version won't be activated until this restart.
+
+ When Archi restarts, the plugin confirms that the new version is operational:
+
+
It is possible to automate this new version checking each time Archi starts by checking the Automatically check for update at startup check box.
+If Archi fails to access Internet because you are behind a corporate proxy, you need to manually edit the Archi.ini configuration file (please refer to Archi documentation to get more information about the Archi.ini file):
++
Databases
+This section displays the list with all the databases that have been defined in the plugin. If a database is selected, its detail is displayed.
+
+
You may declare several databases. When activating a database plugin action (import from or export to a database, compare a model component with a database, ...), the plugin will allow to choose the database against which the action will be done.
+It's up to you to organize your databases depending your own organization. It may be:
+-
+
- one production and one or several test databases +
- one shared databases across the whole architecture team and another one personal +
- one database containing public models and another one containing more sensitive models +
- ... +
The following actions may be done at this stage:
+-
+
- ^: Move up a database +
- v: Move down a database +
- New: Declare a new database +
- Edit: Edit information about a database +
- Admin: Run administrative tasks on a database +
- Remove: Remove a database definition from the plugin (the database itself stay untouched) +
Declare a new database
+Clicking on the New button allows to declare a new database in the plugin.
+
+ The database information fields become visible and editable. Most of the databases share the same information:
+-
+
- Name: Name of your database. This is a pure text label that has got no meaning to the plugin. It may contain spaces and special characters. +
- Driver: At this stage, the plugin supports the following drivers for SQL databases: +
- MS-SQL Server +
- Microsoft JDBC Driver 8.2 for SQL Server: mssql-jdbc-8.2.2.jre11.jar +
- Supports SQL Server 2017 & 2019 database and Azure SQL databases (as per Microsoft compatibility matrice) +
- MySQL +
- mysql-connector-java-5.1.48.jar +
- Supports MySQL 5.6, 5.7 and 8.0 databases (as per MySQL connectors versions) +
- Supports MariaDB 10.x databases (as per MariaDB vs MySQL compatibility) +
- Oracle +
- orai18n.jar (19.3.0.0) +
- ojdbc10.jar (19.3.0.0) +
- Support Oracle 11.2.0.4, 12.1, 12.2, 18.3 and 19.x databases (as per Oracle compatibility for JDBC drivers) +
- PostGreSQL +
- postgresql-42.2.12.jar +
- Supports PostGreSQL 8.2 and higher databases (as per PostGreSQL JDBC driver about) +
- SQLite +
- sqlite-jdbc-3.30.1.jar +
- Supports SQLite up to 3.30 databases (as per SQLite JDBC readme.md) +
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
It also supports the following driver for NoSQL database:
+-
+
- Neo4J +
- neo4j-jdbc-driver-4.0.0.jar (4.0.0) +
- Supports Neo4J 3.5.x and 4.x databases (as per Neo4J JDBC readme.adoc) +
- Expert mode: When selected, it allows to manually edit the JDBC connection string in case some specific parameters need to be used. +
-
+
-
+
-
+
-
+
- Server or IP: Server where the database stands (may be a DNS entry or an IP address) +
- Port: TCP port on which the database is listening +
- Database: Database name +
- Schema: Schema name +
- Username: Username used to connect to the database (leave empty to use your current Windows credentials to connect to a MS-SQL database) +
- Password: Password used to connect to the database (leave empty to use your current Windows credentials to connect to a MS-SQL database). The small lock button allows to switch between a readable and a hidden password. +
- Export views screenshots: If Yes is selected, the plugin generates a screenshot of all the views during the export process and exports those screenshots to the database. Please note that activate this option will slow down the export process and consume more disk space, but they may be useful depending on your needs. Two options are then available: +
- Border width: number of pixels of the screenshot border, 0 means no border, defaults to 10 pixels +
- Scale factor: allows to increase or decrease the size of the screenshots, defaults to 100 percent. +
-
+
-
+
Regarding SQLite databases, the information to provide is quite specific:
+-
+
- File: Filename containing the database. +
- Browse: Opens a file explorer +
Neo4J databases also require some specific options:
+-
+
- Export graph mode: Archimate allows to have relationships from/to another relationship, which is not allowed in Neo4J graphs. +
- Native mode: In this mode, Archimate relationships are exported as Neo4J relationships (so relationships to/from relationships are not exported to the Neo4J graph). You may prefer this mode in case you do not use relationships to/from relationships in your models. +
- Extended mode: In this mode, Archimate relationships are exported as Neo4J nodes (so relationships to/from relationships are exported to the Neo4J graph, but graph analysis is a bit less straight forward). You may prefer this mode if you use relationships to/from relationships in your models. +
- Empty database: Allows to empty the Neo4J database before exporting your model. +
- Empty database before every export: The database is emptied before a model is exported, thus the database contains a single graph corresponding to your model after the export which eases a model analysis. +
- Leave database content: The database content is left untouched before the model export. +
- Relationships type:Specifies how relationships are created in the Neo4J graph: +
- Use unique "relationships" type: +
- Use typed relationships: +
-
+
-
+
-
+
-
+
-
+
-
+
+
After the information has been filled-in, you may click on:
+-
+
- Check: the plugin tries to connect to the database and reports any error if any +
- Discard: discards the database declaration +
- Save: validates the database declaration +
+
Editing information about a database
+Selecting a database displays its configuration under the list. The Edit button allows to edit its configuration.
+After the information has been filled-in, you may click on:
+-
+
- Check: the plugin tries to connect to the database and reports any error if any +
- Discard: discards the database information update +
- Save: validates the database information update +
+
Changing databases order
+The ^ and v buttons allows to move up and down the databases definitions in the list to order them.
+The database order is meaningless for the plugin, except for the first database which becomes the default database.
+This means that even if you can choose the database for all the actions done by the plugin (import, export, check component versions, ...), this default database will be pre-selected.
+
+
Initializing a database
+Each time the plugin connects to a database, it checks if it has been initialized, i.e. if the required tables already exist. If it is not the case, it asks if it should initialize the database:
+
Please click on the Yes button to initialize the database. You may refer to the database structure page to have more details about the tables that will be created.
+A new popup window is then opened with the status of the database initialization:
+
Online help
+This section is a reminder that an online help is available and can be accesses either by Archi Help / Help content menu, or by a click on the help button which is presented as a blue interrogation mark on all key plugin windows:
+
+
Options tab
+The Options tab shows up the plugin options:
+
Available options are:
+-
+
- Automatically start to export to the default database
+ This option changes the plugin behaviour when a model export is requested:
+-
+
- The plugin shows up the export window and automatically starts to export the model to the default database. +
- The plugin shows up the export window and waits for the user to click on the Export button (default). The default database is pre-selected but it is possible to change the database before the export. +
+ - Automatically close import and export windows on success
+ This option changes the plugin behaviour when a model import or a model export is requested: +-
+
- The import window / export window is automatically closed upon success. +
- The import window / export window stays opened and waits for the user to click on the Close button (default). The user can then review statistics about the number of components that have been imported from or exported to the database. +
+ - Show zero values on import and export windows
+ The option changes the way zero values are displayed on the import and export windows:
+-
+
- A zero value in shown. +
- Zero values are shown as empty boxes (default). +
+ - Check max memory available at startup
+ As the plugin requires memory to work properly, this option allows to check if the Java JVM running Archi has got enough memory (at least 1 GB). This option was mainly useful for older version of Archi (and older version of Java JVM) but the memory should not be an issue with current version of Archi.
+-
+
- The plugin displays an error message at startup when the Java JVM memory is less than 1 GB (default). +
- The plugin won't check for the available memory during its initialization. +
+ - Check for NOT NULL constraints while checking database structure
+ This option adds a NOT NULL constraints check when the plugin performs a database structure check:
+-
+
- The plugin checks for NOT NULL constraints (default). +
- The plugin does not check for NOT NULL constraints. +
+ - Remove model's dirty flag after successful export
+ This option changes the plugin behaviour after a model has been successfully exported to a database:
+-
+
- The model's dirty flag is removed so the model will be considered as saved by Archi (Archi will not ask to save the model to an Archimate file when it is closed). +
- The model's dirty flag is not removed, even after a successful export, so a popup will be displayed when Archi is closed, asking to save the model to an Archimate file. +
+ - Compare model to the database before export
+ This option changes the plugin behaviour when a model export is requested: +-
+
- The plugin compares the model components to the database content and shows up the result in the export window (default). This slows down a bit the export process but the user knows what the export process will export to the database. +
- The plugin does not compare the model to the database before the user clicks on the "Export". This quicks up a bit the export process, but the user does not know in advance what the plugin will export to the database. +
+ - Keep partially imported model in case of error
+ This option changes the plugin behaviour when an issue is raised during a model import:
+-
+
- In case of an error occurs during a model import, the plugin shows up an error message but keeps the partially imported model in Archi. +
- The plugin does not keep the partially imported model (default). +
+ - Show debugging information in context menu
+-
+
- Adds a context menu entry to access debugging information about selected Archimate component (ID, version, checksum, database status, ...). +
- The debug context menu entry will be hidden (default). +
+ - Append suffix when import component in copy mode
+-
+
- It is possible to change the suffix that is added to components' name when the are imported in copy mode from the database (please refer to the import model page for more information). +
+ - Default components import mode
+-
+
- Template mode (default): Defines the template mode as the default import mode. +
- Force shared mode: Defines the shared mode as the default import mode. +
- Force copy mode: Defines the copy mode as the default import mode. +
+
+
Logger tab
+ The logger tab allows to specify a log file and the level of information to store in this log file.
+
The plugin logs can be:
+-
+
- Disabled +
- Configured using simple mode +
- Configured using expert mode +
+
Disabled
+When disabled, the logger does not generate any log nor error message.
+
+
Simple mode
+The simple mode allows to configure the logger in a very simple way:
+
+
The information to provide is:
+-
+
- Logger level: Please choose the level of details you wish to see in the log file. +
- Log filename: Please fill in the filename in which the logger will append the log information. The filename field is highlighted with a green border if the log filename exists and with a red border if the log filename does not exist. +
+
Expert mode
+The expert mode allows to manually configure the logger configuration:
+
+
The logger is managed through the Log4J 1.2 library and you may fill-in your own configuration in the text editor. Please note that any error in this configuration may avoid the logger to work correctly.
+You may as well select the Include SQL requests in trace mode should you wish to include the SQL requests sent to the database in your log file. Please note that those SQL requests are logged if the logger is configured in trace level only.
+
+
In expert mode, you are provided with a simple text editor and you may configure the Log4j logger manually (on Windows, it is necessary to double the backslashes).
++ This mode is very powerful, as you may specify several log files, with different level of information. You may also change the lines format.
+
+ This option must be reserved to people who have knowledge about Log4j as a bad configuration can stop the plugin from working correctly. In all cases, it is always possible to restore a safe and working configuration using the "Restore defaults" button. + + diff --git a/sources/help/html/exportModel.html b/sources/help/html/exportModel.html index fe7b8dfc..9d707075 100644 --- a/sources/help/html/exportModel.html +++ b/sources/help/html/exportModel.html @@ -1,101 +1,128 @@ - - + - - -
Export a model to a database
--This page describes how to export a model in a database.
-
-To export a model to a database, you first need to select the model to export, then either access the File / Export / Export model to database menu option of Archi, or right-click on the model's name and select the Export model to database context menu option.
-
The graphical interface
-As every window of the database plugin, the export window is split in 5 zones: --
-
- The left zone shows the plugin's logo and the list of actions. -
- The right hand-side of the export window is split in 3 zones:
-
-
-
- The database selection -
- The versions of the model -
- The model's components -
-
-
-
The database selection
-This section allows to select the database where the model should be exported. The databases are presented in the order defined on the preference page.-
-The "set preferences" button allows to directly open the preference page to update the database list or set preferences.
-
-Please note that it is possible to export any model in any database, even if the model has been imported from another database or loaded from an Archimate file.
-
The versions of the model
-This section lists the versions of the model that already exist in the database.-
-The "Now" line represents the version that will be exported in the database. It allows to change the model name and purpose, but also to set a release note.
-
-
The model's components
-This section lists how many components are present in your model.-
-The plugin can also show the comparison between the model as it is in Archi and as it is in the database.
-
-To achieve this comparison, the plugin uses the components ID to check if it already exists in the database: -
-
-
- If the component does not exist in the database:
-
-
- The component is assumed to be a new component created by Archi, either manually or loaded from an Archimate file --> The component will be created in the database. -
- - If the component does exist in the database:
-
-
-
- The plugin calculates the current checksum and retrieves all the other needed checksums and versions from the database:
-
-
- The component's "initial version and checksum" that is the latest version in the database that has got the same checksum, -
- The component's "latest version and checksum" that is the latest version in the database that is part of the same model, -
- The component's "latest database version and checksum" that is the latest version in the database whatever the model the component is in. -
- - Then it is then possible to compare all the versions and checksums:
-
-
- If the "latest version" and the "latest database version" are equal, then the component has not been updated by another model (thus, only the "current checksum" and "initial checksum" are relevant):
-
-
- If the "current checksum" and "initial checksum" are identical then the component is in sync with the database --> it does not need to be exported to the database -
- If the "current checksum" and "initial checksum" differ then the component has been updated in Archi --> it needs to be exported to the database -
- - If the "database version" is zero then the component does not exist anymore in the latest version of the model in the database --> it needs to be deleted in Archi -
- If the "current checksum" is identical to the "latest database checksum" then the component is in sync with the database --> it does not need to be exported to the database -
- If the "initial checksum" differs from the the "current checksum" then the component has been updated in Archi -
- If the "initial checksum" differs from the the "database checksum" then the component has been updated in the database
-
-
- If the component has been updated in Archi but not in the database --> it needs to be exported to the database -
- If the component has been updated in the database but not in Archi --> it needs to be updated in Archi with the values from the database -
- If the component has been updated in both Archi and the database:
-
-
- If the "current checksum" and "database checksum" are identical, then the same modifications have been done in Archi and in the database --> it does not need to be exported to the database -
- If they differ, then the modifications done in Archi and in the database are different --> there is a conflict that needs to be manually resolved by the user -
-
-
- - If the "latest version" and the "latest database version" are equal, then the component has not been updated by another model (thus, only the "current checksum" and "initial checksum" are relevant):
- - The plugin calculates the current checksum and retrieves all the other needed checksums and versions from the database:
-The plugin shows the number of components in each situation, either automatically if configured in the preferences, either when the user clicks on the "Compare model to the database" button.
-
-
The export process
-When the user clicks on the "export" button, the plugin: --
-
- Recalculates the status of all the components as it may have changed since the last comparison, -
- Imports missing components from the database and update those that have been updated in the database, -
- Exports components that have been updated in Archi, -
- References all the model components as been pat of the model (even those that do not need to be exported), -
- If conflicts are detected, the user is invited to resolve them. -
-At the end of the export process, the progress bar is replaced by a status message with a color that highlights the export status (green if successful, yellow in case of error). In case of any error, the export is rolled-back and the database is left untouched. This behavior allows to guarantee the database coherence.
-
-The export to the database cannot be undone, but in case some components have been imported or updated during the export process, the whole import/update can be undone using Archi undo/redo mechanism (menu Undo/Redo or keys ctrl-Z/ctrl-Y).
-
-
Conflict resolution
-Undo / redo
-All the imports or updates done during the export process can be undone using the Ctrl-Z key or Archi's menu, and redone using the Ctrl-Y key or Archi's menu.-
-Nevertheless, one a new version is written to the database, it cannot be undone. - - \ No newline at end of file + + +
Export a model to a database
++ This page describes how to export a model in a database.
+
+ To export a model to a database, you first need to select the model to export, then either access the File / Export / Export model to database menu option of Archi, or right-click on the model's name and select the Export model to database context menu option.
+
The graphical interface
+ As every window of the database plugin, the export window is split in 5 zones: +-
+
- The left zone shows the plugin's logo and the list of steps to finish the action. +
- The right hand-side of the export window is split in 3 zones:
+
-
+
- The database selection +
- The model versions +
- The model's components +
+
+
+
The database selection
+ This section allows to select the database where the model should be exported. The databases are presented in the order defined on the preferences page and the first one is pre-selected as the default database.+
+ The Set preferences button allows to directly open the preference page to update the database list or set preferences.
+
+ Please note that it is possible to export any model in any database, even if the model has been imported from another database or loaded from an Archimate file.
+
The model versions
+ This section lists the versions of the model that already exist in the selected database. As every database is independent of the others, it may contain different versions of your model. Thus changing the database in the database selection drop list will of course impact the model versions.+
+ The "Now" line represents the version that will be exported in the database. It allows to change the model name and purpose, but also to set a release note to help remembering the changes that have been done in this model version.
+
+
The model's components
++ This section shows statistics about the model, as it is in Archi and how it compares to the selected database.
+The Total column indicates how many components are present in your current model in Archi.
+If the plugin preferences states that the it should automatically compare the model to the database, then the other columns are filled in, otherwise they are empty. The Compare model to the database allows to (re)launch the comparison process and to fill-in the comparison columns. This comparison is read-only, it keeps your database untouched.
+To achieve this comparison, the plugin uses Archi's internal IDs to check if those components already exists in the database. A checksum is automatically calculated by the plugin and allows to determine if the current component in Archi is identical or different from the database.
+The Archi columns summarize how the current Archi model compares to the database:
+-
+
- New: Counts the components that are new in the model from the last model version in the database. +
- Updated: Counts the components that have been updated since the last model version in the database +
- Deleted: Counts the components that have been deleted from the model since the last model version in the database +
The Database columns summarize are used in the situation where you and other people imported the same model in Archi and export their own model updates to the database while the other are still working on their own copy of the model. In this scenario, the columns summarize how the latest version of the model in the database compares to your current version in Archi:
+-
+
- New: Counts the new components that have been created in the model by the other person. +
- Updated: Counts the new components that have been updated in the model by the other person. This situation occurs if the other person has updated the components but you haven't thus this doesn't lead to any conflict. +
- Deleted: Counts the new components that have been deleted in the model by the other person. +
A specific procedure is in place to detect and solve conflicts:
+-
+
- Conflicts: Counts the new components that have been updated by the other person, but that have been updated by you in your current model. Thus, the updates done by you and the other person are conflicting. +
-
+
+
+
The export process
+ When the user clicks on the "export" button, the plugin: +-
+
- Recalculates the status of all the components as it may have changed since the last comparison, +
- Imports missing components from the database and update those that have been updated in the database, +
- Exports components that have been updated in Archi, +
- References all the model components as been pat of the model (even those that do not need to be exported), +
- If conflicts are detected, the user is invited to resolve them. +
+ At the end of the export process, the progress bar is replaced by a status message with a color that highlights the export status (green if successful, yellow in case of error). In case of any error, the export is rolled-back and the database is left untouched. This behavior allows to guarantee the database coherence.
+
+ The export to the database cannot be undone, but in case some components have been imported or updated during the export process, the whole import/update can be undone using Archi undo/redo mechanism (menu Undo/Redo or keys ctrl-Z/ctrl-Y).
+
+
Version management
+If the component does not exist in the database:
+-
+
- The component is assumed to be a new component created by Archi, either manually or loaded from an Archimate file --> The component will be created in the database. +
-
+
- The plugin calculates the current checksum and retrieves all the other needed checksums and versions from the database:
+
-
+
- The component's "initial version and checksum" that is the latest version in the database that has got the same checksum, +
- The component's "latest version and checksum" that is the latest version in the database that is part of the same model, +
- The component's "latest database version and checksum" that is the latest version in the database whatever the model the component is in. +
+ - Then it is then possible to compare all the versions and checksums:
+
-
+
- If the "latest version" and the "latest database version" are equal, then the component has not been updated by another model (thus, only the "current checksum" and "initial checksum" are relevant):
+
-
+
- If the "current checksum" and "initial checksum" are identical then the component is in sync with the database --> it does not need to be exported to the database +
- If the "current checksum" and "initial checksum" differ then the component has been updated in Archi --> it needs to be exported to the database +
+ - If the "database version" is zero then the component does not exist anymore in the latest version of the model in the database --> it needs to be deleted in Archi +
- If the "current checksum" is identical to the "latest database checksum" then the component is in sync with the database --> it does not need to be exported to the database +
- If the "initial checksum" differs from the the "current checksum" then the component has been updated in Archi +
- If the "initial checksum" differs from the the "database checksum" then the component has been updated in the database
+
-
+
- If the component has been updated in Archi but not in the database --> it needs to be exported to the database +
- If the component has been updated in the database but not in Archi --> it needs to be updated in Archi with the values from the database +
- If the component has been updated in both Archi and the database:
+
-
+
- If the "current checksum" and "database checksum" are identical, then the same modifications have been done in Archi and in the database --> it does not need to be exported to the database +
- If they differ, then the modifications done in Archi and in the database are different --> there is a conflict that needs to be manually resolved by the user +
+
+
+ - If the "latest version" and the "latest database version" are equal, then the component has not been updated by another model (thus, only the "current checksum" and "initial checksum" are relevant):
+
Conflict resolution
+
+
Undo / redo
+ All the modifications done on your model during the export process, because of new, updated, deleted or conflicting components in the database, can be undone using the Ctrl-Z key or Archi's Edit / Undo menu, and redone using the Ctrl-Y key or Archi's Edit / Redo menu.+
+ Exports to a database cannot be undone. Nevertheless, as all models and components are versioned in the database, it is always possible to open a previous version of a model or a component. + +