Skip to content
Crevia DocumentationDesign & Issuance PlatformV11
English user guide
CREVIA V11 · ENGLISH USER GUIDE

Supported Exchange Formats

Appendices6 min read
On this page

8.2 Supported Exchange Formats

Import maps/writes external records; export creates a scoped copy. Neither is database backup/recovery, nor are they symmetrical converters. License and role requirements apply.

8.2.1 Import Sources

Source Selection Preparation/limits
Excel .xlsx, .xls Sheet/header/start row; legacy .xls needs compatible 64-bit access components or proper conversion to .xlsx.
JSON .json Valid JSON and actual record-array path, without comments/trailing commas or confusing outer metadata.
Markdown .md, .markdown Consistent tables/record structures selected by read settings.
XML .xml Correct record path; DTD/external entities are disabled, so do not depend on external resources.
CSV .csv Encoding/separator/qualifier and proper comma/quote/newline escaping.
Word Selector includes .docx, .doc Use actual .docx; convert old .doc with office software, not a suffix change.

An allowed suffix does not guarantee protected/damaged/complex/nested content is readable. Test a redacted copy. PDF, scans, Access, and SQLite are not these six import sources; renaming does not add support.

8.2.2 Export Targets

Current batch export offers Access, JSON, XML, SQLite, Excel, and Markdown, with data only, photos only, or both. CSV/Word are not in this batch-export list. Report export is a separate preview capability.

Format Data file Receiver check
Excel Records.xlsx Sheet Records, identifiers/dates/long text/count without trusting auto-types.
JSON Records.json Actual names, NULLs, and date representation.
XML Records.xml Data/schema structure; use its real nodes, not another source's path.
SQLite Records.sqlite Exchange table Records, not the original complete database.
Access Records.accdb Compatible access environment for creation and reading.
Markdown Records.md Tables, multiline/special-character display and rereading.

Files are inside the generated output directory. Photos-only omits the personnel table; result materials such as ExportResults.json are not personnel data. Reconcile image success/unique naming separately. Chosen fields/current scope do not preserve every original table, relationship, trigger, login, or grant. Use Chapter 6 backups for full recovery.

Manual illustrationRequirements:

Figure 8.2-1. Compare English import source and export format choices plus demonstration Records/result files. Label asymmetric capabilities and hide live data/paths/projects.

8.2.3 Fields, Dates, NULLs, and Identifiers

Agree meanings as well as names. These are demonstration conventions, not schema automatically created by CREVIA:

Field Meaning/example Preparation
EmployeeNo Unique business identifier 000125 Text from origin; no blanks/duplicates; suitability as match key depends on the main table.
FullName Alex Morgan Not inherently unique; retain meaningful spaces.
Department Visitor Services Display name, not numeric foreign-key ID.
ValidUntil 2027-12-31 Unambiguous date; validate target/time/conversion.
PhotoFile Filename/path Configure photo synchronization; do not map path text as binary contents.

Empty strings, omitted fields, and NULL differ. Test whether blank updates overwrite existing values on a sample with old content. Destination text cannot restore already-truncated source identifiers. CSV "Morgan, Alex" represents one comma-containing value with the matching separator/qualifier; validate the raw file and preview, not only an office spreadsheet's appearance.

8.2.4 Complete Small Exchange Example

This valid fictitious JSON has two data records, no binary photos, and performs no automatic database writes:

[
  {
    "EmployeeNo": "000125",
    "FullName": "Alex Morgan",
    "Department": "Visitor Services",
    "ValidUntil": "2027-12-31"
  },
  {
    "EmployeeNo": "000126",
    "FullName": "Taylor Reed",
    "Department": "Visitor Services",
    "ValidUntil": "2027-12-31"
  }
]
  1. Prepare actual writable main-table targets in an isolated database; do not alter production just to copy this schema.
  2. Read JSON in COC and confirm two rows/four business fields. Select the actual root array if a path is required.
  3. Map ID/name/date to actual fields. Resolve a reference department's name-to-ID rules separately; stop if uncertain rather than writing text into an integer key.
  4. Disable photos for this example, check, then execute Add Only only in the test database and retain success/failure/skip counts.
  5. Refresh/reread both numbers, zeros, names, department, and dates at the correct target.
  6. Filter the two records and export Excel or JSON, checking scope/fields and opening the actual result for comparison.

Before repeating, inspect existing rows. Add Only is not update. Match-key updates require the appropriate mode and unique main-table field. Never delete real same-number people to obtain two successful examples.

8.2.5 Photos and Result Acceptance

Validate photo synchronization separately, preferably using stable identifiers and explicit extensions/subfolders/missing/multiple policies. Source paths must be reachable from the actual workstation. The current 20 MB per-file rejection threshold is a limit, not a recommended photo size. Balance suitable image quality and verified decoding/writes. Visible interface photos are not automatically binary-field export support.

Reconcile source/executable/success/failure/skip totals, identifier/date/NULL samples, photo ownership, and destination. The first 200 preview rows are neither the total nor a batch limit. Preserve partial results, read back committed rows, and retry only the required part; stop/close/error does not establish complete rollback.