Manage Versions | Manage Database - Database Compression | Scheduled Database Compression | Manage Database – Manage Related Tables | Manage Database - Manage SchemasLock a Schema |

 Delete a Schema | Edit Name of Schema | Review Schema Field Mapping | View Automated Upload Schema (Premium Feature) | Database Restoration

Manage Versions


In the Manage Versions section, Administrators can view and delete any user's active or submitted edit and upload versions. Users have a maximum of ten versions they can have at any given time and will not be allowed to start and upload or create a new edit session until one is removed or approved. In this section an Admin can delete the user's version, however, it is a permanent action and cannot be undone. Performing a delete on a version will disrupt the system so ensure all users are logged out of VEP at the time of deletion.


Manage Database - Database Compression

In the Manage Database section, Administrators can compress their database to remove unused states and data, and re-indexes existing fields to improve efficiency in the geodatabase. Thus, periodic compression is critical to maintaining good database performance.


To run a database compression, first ensure that users are not accessing the system and then do click the Compress Database button.


Once compression is initiated the system will be inaccessible. A status bar showing the progression of the compression will display. It will take a varied amount of time depending on the last time a compression was run and the amount of versioned editing that took place. After the compression is completed, access to the system will be restored.


As a best practice compression is recommended at least once a week, or more frequently for higher volumes of editing.



Scheduled Database Compression

Database compression may also be scheduled by users at a date, time, and frequency of their choosing. However, database compressions cannot be scheduled within 12 hours of another write-activity on the database such as a cross-jurisdictional validation or data aggregation. A warning message will appear if VEP detects a scheduling conflict with another database activity. 


To enable a single or recurring database compression on your local VEP instance Admins may perform the following steps:


1. Navigate to Database Management > Manage Database > Compress Database page.


2. Fill out the Date and Time fields in the Compress Database tab. 

a. Select one of the three Recurrence Frequency options to have the job on a regular weekly, bi-weekly or monthly interval. For one-time database compressions, leave the Recurrence Frequency option as 'None'


3. Select the Scheduled Compress DB button to schedule the compression job.


4. Scheduled database compressions will appear with an entry under the Scheduled Database Compression tab listing the pending job details. 

a. Individual compression jobs not yet initiated can be canceled via the 'X' symbol in the Actions column

b. Completed database compressions will appear with an entry under the Database Compression tab listing the completed job details





Manage Database – Manage Related Tables

An additional feature available to Administrators is the ability to delete Related (Appendix) tables from VEP. 


If a related table was uploaded as part of an earlier editing session and is no longer needed, these tables can be removed:


1.  Navigate to Database Management > Manage DatabaseManage Related Tables page.


2. Select the desired related table checkbox from the table in the Delete Related Tables table.


3. Click the Delete Related Table button.



Manage Database - Manage Schemas

Admin users can view and manage saved Native Schemas in the Manage Schemas tab.


Lock a Schema

Admin users can 'lock' a schema so that they can prevent non-admin users from modifying a schema. Users will not be able to update the existing schema in the Upload workflow, nor will users be able to save changes made to a schema in the Custom Downloads workflow. Locked schemas will display a lock symbol next to their name in the schema table under the Manage Schemas tab:



To lock a schema: 

1. Navigate to Database Management > Manage DatabaseManage Schemas page.

 2. Select the corresponding checkbox in the Schema Lock column in the table listing all schemas.


Delete a Schema

To delete a schema, Admin users can do the following:


1.  Navigate to Database Management > Manage DatabaseManage Schemas page.


2. To delete a Native Schema, click the Drop Schema icon (X) under the Actions column for the corresponding schema. 


3. Confirm the deletion in the Confirm pop-up box.



Edit Name of Schema

To edit a schema, Admin users can do the following:


1.  Navigate to Database Management > Manage DatabaseManage Schemas page.


2. Click the pencil icon under the Actions column for the corresponding schema. 


3. Use the Edit Schema Mapping window to rename the schema. Click Save to save your changes or Close to exit without saving.


Review Schema Field Mapping

To review the field mapping configuration of a schema, click the Download Schema Icon under the Actions column of the corresponding schema.


 

A spreadsheet with the saved Schema configurations will be downloaded. Open the spreadsheet to view the saved field mapping settings for the Native Schema. Here, viewers will see the VEP Field Name, VEP Field Type, Native Field Name, Native Field Alias, and Native Field Type.



View Automated Upload Schema (Premium Feature)

Customers with access to the Automated Upload premium service through their subscription will be able to review the schemas associated with their automated uploads configuration file. When data is uploaded in the Uploads workflow, users can save the schema associated with the upload to be used for future automated uploads in VEP, which is indicated by the checked box in the Automated Uploads column.



Database Restoration

Database restoration is an available option if a user wants to revert to a prior version of their geospatial data in VEP. This functionality is not available through VEP but can be requested through our Support Center. When a user requests a Database Restoration, DATAMARK reverts the database to an earlier snapshot at a specific point in time, up to two days prior to the request. The restored database will then mimic that earlier snapshot of the data, and any work performed after the specified timestamp will no longer be accessible.


As an example, User A creates an edit session at 2 pm on Monday, makes and saves an edit session. Then the System Admin for the same user instance requests a Database Restore from the previous night, Sunday. The VEP system will roll back the user's dataset to the database snapshot from Sunday night. Therefore, User A's edits and edit session will not be accessible as they were created on Monday after the restored snapshot from Sunday night.


Below is a full list of areas potentially impacted by a database restoration:

  • Restoration Time
    • The restoration time is the time at which the snapshot of the user's database is created in AWS. All the items listed below will be impacted based on the restoration time. 
  • Edit sessions/ Admin / Review:
    • All the edit sessions (including submitted, rejected, approved, and active) and the associated edits that are performed after the restoration time will be removed and no longer available. 
    • All the edit sessions (including submitted, rejected, approved, and active) and the associated edits that are performed before the restoration time will be retained. 
  • Manage Versions: 
    • Manually deleted versions cannot be brought back in any case before or after the restoration time, as indicated by the warning message. 
    • The edit session entries for active rejected and submitted sessions made after the restoration time will be removed from the list. 
  • Uploads:
    • All the Uploads (adds, updates, deletes) posted to the default database up to the restoration time will be retained.  
    • All the Uploads (adds, updates, deletes) posted to default and pending approval after the restoration time will not be available. 
  • Validations:
    • The validation anomalies generated as part of the validation runs after the restoration time will be removed including the validation job details. 
    • The validation anomalies that were created before the restoration time will be retained. 
  • Dashboard: 
    • The validation results ran after the restoration time will not be included in the dashboard. 
    • The dashboard will show the validation results from the latest job that was run before the restoration time. 
  • Markup Updates:
    • The Markup exceptions are updated via VEP (through the Map interface and Markup upload options) after the restoration time will be lost. 
    • The Markup exceptions updated before restoration time will be retained. 
  • Downloads: 
    • All the Downloads entries created after the restoration time will be removed. 
    • The downloads performed before the backup creation time will still be accessible. 
  • Manage Database:
    • The related tables deleted after the restoration time will no longer be available. 
    • The related tables deleted before the restoration time will be restored. 
  • Change Log:
    • Change logs (approved sessions) will not display the details for actions performed after the restoration time. 
    • Change logs (approved sessions) for actions performed before the restoration time will be available. 
  • User Reports:
    • User reports created after the restoration time will be removed. 
    • User reports generated before the backup creation will still be accessible.