The Export CORE Data File command allows you to generate an XML or structured legacy text representation of your repository, your project, or a subset thereof. The export command allows you to create baselines, backups, interchange files, version upgrades, and much more. The binary representations used for the native local and remote repositories in CORE provide the greatest performance, but they are not the best formats for archival or exchange purposes. This is where the export formats shine.
Given the richness and power of CORE, the export command includes a host of options allowing you to select the desired data.
![]() |
When working with local repositories, export your data regularly to serve as a project backup. CORE Server automatically backs up its data on a regularly scheduled interval of hot backups. However, only you can back up your local repository. |
To help streamline and simplify your project operations, standard options have been bundled together to best support certain export cases. However, you have ultimate control.
Beginning with CORE 5.0, the default file format was changed from a structured text format to an XML format. While legacy formats are still supported, the XML format contains the richest data representation and provides you the most control over export options and import behavior. Unless there is a specific reason, we strongly recommend selecting the current XML format. Previous file formats allow for exchange with older versions of CORE but do not include all of the richness introduced since CORE 5.0.
Formats supported include:
CORE 5.x/6.x/7.x/8.x/9.x (XML) - the current XML-based CORE file format. Using XML provides a common a rich, standardized syntax for CORE data files. For those interested in reading CORE data files in 3rd party tools, the XML DTD is embedded in the XML file, so the structure is self-documenting.
4.x Format - for exchange with CORE 4.x users. This format does not support versioning, perspectives, or the full richness of CORE's stored views which provide the presentation layer to complement the technical content.
3.x Format – for exchange with CORE 3.x users. This format does not support attribute change tracking (who last changed an attribute and when), versioning, perspectives, or the full richness of CORE's stored views which provide the presentation layer to complement the technical content.
2.x Format – for exchange with CORE 2.x users. This format does not support attribute change tracking (who last changed an attribute and when), versioning, perspectives, or the full richness of CORE's stored views which provide the presentation layer to complement the technical content.
The Export drop-down presents the list of export scenarios supported. These scenarios represent a specific combination of options packaged to best support standard export cases. As an export is selected from the drop-down, the Options pane will shift to show the applicable settings for the export scenario. If the pane is greyed out, the options are informational only, informing you of what options are included in the scenario. If the pane is white, you may change the options presented.
The options vary for XML and legacy exports. XML exports provide not only the richest data set but also the richest options.
CORE 5.x/6.x/7.x/8.x/9.x (XML)
Project Backup - the default export scenario, project backup creates a full XML backup file containing the projects selected in the projects pane. This includes the complete schema definitions, the database, and utility information (folders, filters, hierarchy definitions, icon templates, and sort definitions). When backing up or archiving a specific project, this is the best option. Note, however, that this does not include the defined users and groups. Therefore, if you are archiving a project, you should also archive a user and group export.
Project Baseline - creates a full export representation equivalent to Project Backup but proceeds to erase the merge history after the import is completed. This option is valuable when working with distributed team members who will be modifying the system definition in parallel without benefit of the CORE Server to enable collaboration. Distributed team members can then send their updates back to the project administrator or merge manager using the Project Database Changes export.
Project Database Changes - includes only the subset of changes made since merge history was last erased. When working as part of a distributed team without benefit of a CORE Server, this allows you to export your work for merge back into the authoritative project repository.
Project Template - beyond the project data itself, CORE projects have a rich framework - the schema meta-language, folders to help structure data, filters to display only the data of interest, hierarchy definitions to display hierarchies in diagrams and reports, icon templates to customize diagram representations, sort definitions to control the sort and display of element lists, table definitions to define the import and export of data to other formats, and project preferences to control the presentation of project information. The project template export packages all of this framework into a single export file to serve as a starting point for future projects. Equivalently, you could import a project and erase the database, but this scenario allows you to share your framework without sharing your data.
Project Schema - is equivalent to Project Template with the exception of folders (not included in project schema).
Users & Groups - includes only the user and group definitions, their properties, and the individual user settings (if selected in the options pane). When distributed teams are working on a common project, the users & groups export allows them to share a common definition of accounts for access control purposes.
Full Repository Backup - includes all projects, project data, and users & groups in a single XML file. This format is most appropriate for backing up a repository or preparing to migrate to a new version of CORE.
Advanced Options - if one of the predefined packages does not meet your needs, advanced options allows you to select the specific options desired.
Legacy Formats
Project Database - the default export scenario, project database exports your elements, attributes, relationships, and structures. Optionally, it includes your view descriptions (if checked). You also have the option of marking the file to automatically erase merge history after import (useful in distributed team scenarios).
Project Database Changes - includes only the subset of changes made since merge history was last erased. When working as part of a distributed team without benefit of a CORE Server, this allows you to export your work for merge back into the authoritative project repository.
Project Folders - exports your folder structure (without any additional data) for use on a different project.
Project Schema - exports your class, attribute, relation, and facility customizations for use on another project.
Users Settings - includes only the user and group definitions. When distributed teams are working on a common project, the users & groups export allows them to share a common definition of accounts for access control purposes.
The comment field allows the user to enter a descriptive comment to be placed at the top of the export file to help describe the file. By default, the comment string displays when the export occurred and who performed the export.
![]() |
What permissions are required to export the database? Any user with read permission to a project can export the database. However, only the data that the user has permission to read will be exported (for example, if the user has not been given read permission to a requirement, the requirement will not be exported). Therefore, it is highly recommended that only users with administrator permission export projects for baseline, archival, or exchange purposes. |