Exporting Data with dbSlice: A Guide to All 11 Formats

Turn a database table, view, or query into a file that fits the next step in your workflow: an integration payload, a spreadsheet, a local SQLite database, a SQL script, or a list of record keys.

Product walkthrough · English edition · October 2026
Example: SQL Server MASTER → item → JSON · 11,172 synthetic records

The Export tab brings source selection, filtering, file format, and execution feedback into one workspace. This guide walks through its controls, reproduces the configuration shown in the supplied demonstration, and explains what each output actually contains.

The screenshots show dbSlice build 2.3.20260913.1655. Format behavior was also checked against the accompanying application source. Labels and format availability can vary by installed version and license. In the reviewed implementation, evaluation mode allows CSV exports; the other formats require activation.

1. Find your way around the Export tab

Figure 1. The Export tab with the format list expanded. The source is the synthetic item table on the saved SQL Server profile named MASTER.

There are two main sections. Source identifies what dbSlice reads. Target determines the file it creates. The action buttons, progress indicator, and execution log appear below them.

The name MASTER is a saved connection profile in this demonstration. It does not refer to SQL Server's system database named master. Connection credentials are managed separately and are not part of the examples in this article.

Use a unique, non-null key that stays stable during the export. A primary key such as id is a natural choice. For a custom query, return the key column in the result and ensure joins have not duplicated it.

Page size is a batch size. Setting it to 10,000 does not limit the entire export to 10,000 rows and does not create a separate file for every page. Use a filter or query to define a smaller dataset.

Export reads the source without applying INSERT, UPDATE, or DELETE operations to it. It does write the selected output file. In particular, choosing SQLite creates a local database file; choosing SQL generates text that is only executed if you later run it yourself.

2. Walkthrough: export 11,172 items to JSON

This example uses the synthetic sales dataset from the earlier dbSlice articles. The source table contains 11,172 items with identifiers, category references, names, prices, quantities, status values, and creation timestamps.

1. Open Export and choose MASTER [SQL Server] under Connection.
2. Click Connect and select Table, then item.
3. Set Key column (unique) to id.
4. Leave WHERE filter unchecked to include the full table.
5. Choose JSON from Format.
6. Use Browse to choose a new output file, for example C:\dbSliceDemo\exports\items.json.
7. Set Page (rows) to 10,000.
8. Leave Obfuscate values unchecked for this synthetic dataset.
9. Click Export and follow the execution log.
10. Open the resulting file and verify its structure, row count, and representative values.

The supplied demonstration reports:

Export completed: 11,172 rows, 2,623 KB in 0.1s.

The displayed duration is an observation from the supplied run, not a performance guarantee or a cross-format benchmark. Network conditions, database activity, row width, disk performance, and output format affect subsequent runs. Progress messages may be throttled, so the log need not contain one line for every batch.

The first record shown in the demonstration has this structure:

[
  {
    "id": 1,
    "category_id": 1,
    "sku": "SKU-00000001",
    "name": "Demo Item 00000001",
    "unit_price": 10.00,
    "stock_quantity": 13,
    "is_active": 1,
    "created_at": "2023-01-01T00:00:00.0000000"
  }
]

This is a one-record excerpt, not the complete 11,172-record file. The numeric is_active value reflects this source representation; a JSON export does not automatically turn every 0/1 field into a Boolean.

3. Choose a format by the next task

The dropdown contains 11 options. Ten produce a representation of selected row data or keys. SQL — MERGE / upsert produces a parameterized command template from the source structure.

4. Data files: CSV, JSON, and XML

CSV: a compact, widely usable table

CSV writes a header followed by comma-separated records. The reviewed exporter uses UTF-8 with a byte-order mark. Values containing commas, quotation marks, or line breaks are quoted, and quotation marks inside a field are escaped by doubling them.

The following shortened example uses only three columns for readability:

id,sku,unit_price
1,SKU-00000001,10.00
2,SKU-00000002,19.37

Choose CSV for flat data exchange and bulk import workflows. Configure the receiving tool to use a comma delimiter and the intended column types. A CSV file does not carry the original database schema, and a spreadsheet may reinterpret identifiers or dates when opening it. In this exporter, null values and empty strings can both appear as empty fields; use JSON if that distinction matters to the consumer.

JSON: structured records for applications

JSON produces a single array of objects, with source column names as property names. Numbers, Booleans, and nulls retain corresponding JSON representations where supported by their source values. Dates are serialized as strings; binary values use Base64.

Choose JSON for test fixtures, integration payloads, and processing scripts. The output is a standard JSON array, not newline-delimited JSON. A consumer that loads the entire document into memory needs enough capacity for the complete file, independently of dbSlice's page size.

XML: an element-based document

XML writes a DocumentElement root, an element for each row, and child elements for the exported columns. The object name supplies the row element name. Names are adjusted when needed to form valid XML element names.

<DocumentElement>
  <item>
    <id>1</id>
    <sku>SKU-00000001</sku>
    <unit_price>10.00</unit_price>
  </item>
</DocumentElement>

This shortened example shows the layout. Null-valued columns are omitted from the row element in the reviewed exporter. The file is a data document, without an accompanying XSD. Match the element names and null convention to the receiving system's expectations.

5. Human-readable outputs: Markdown and Excel

Markdown: include a small dataset in a document

Markdown creates a table with column headings and an optional title derived from the object name. It is useful for README files, issue reports, and technical articles where a small sample should be visible alongside an explanation.

| id | sku | unit_price |
| --- | --- | --- |
| 1 | SKU-00000001 | 10.00 |
| 2 | SKU-00000002 | 19.37 |

Use a filter such as id <= 20 to keep the result readable. Exporting hundreds of thousands of rows as a Markdown table is possible to request, but produces a document that is difficult to browse and render.

Excel: a worksheet for review and analysis

Excel creates an .xlsx workbook containing one worksheet, a header row, and the exported records. The exporter assigns cell values for supported source types and adjusts column widths from a sample of the data.

Choose Excel when the next user wants to inspect, sort, filter, or chart the results in a spreadsheet. Check long numeric identifiers, precision-sensitive values, and date cells before distributing the file.

The reviewed Excel writer builds the workbook in memory. Reducing Page (rows) changes database fetch batches but does not make the workbook itself a streaming output. Filter large datasets to a useful working subset, or choose CSV or JSON for a file-processing workflow.

6. SQLite: export a table you can query locally

SQLite database (.db) creates a local database file and a table based on the selected source columns and key. Records are inserted in batches. Set the target object name to a simple table name, such as item, and choose a new .db file.

The output can then be opened with a SQLite-compatible database tool. For example:

SELECT COUNT(*) AS row_count FROM item;

SELECT id, sku, unit_price
FROM item
ORDER BY id
LIMIT 10;

This is useful for a portable demonstration, a local lookup dataset, or an extract that needs SQL queries. A single Export operation handles the selected object. It should not be described as a complete source-database backup: do not assume all foreign keys, secondary indexes, triggers, stored procedures, or related tables have been reproduced.

Choose the output path carefully. The reviewed SQLite export replaces an existing file at that path before creating the exported table. It does not append another table to an existing database. Use Synchronize when the task is to update a table in an existing target database.

7. SQL outputs: INSERT, UPDATE, and MERGE / upsert

SQL INSERT: one statement for every selected row

SQL INSERT writes literal values into INSERT statements. A shortened example is:

INSERT INTO item (id, sku, unit_price)
VALUES (1, 'SKU-00000001', 10.00);

The target table must already exist when you execute the script. Existing keys, identity-column rules, and constraints can affect execution. This format exports data statements; it does not perform the load during Export and does not include a complete database schema.

SQL UPDATE: match existing records by the key

SQL UPDATE writes a statement for each source row, with the selected key in its WHERE condition and the other columns in SET assignments.

UPDATE item
SET sku = 'SKU-00000001', unit_price = 10.00
WHERE id = 1;

This shortened example illustrates the pattern. The actual export includes the other non-key columns returned by the source. UPDATE does not insert a missing record and is not a comparison report of changed fields: it generates assignments from the selected data.

For both INSERT and UPDATE, inspect object names, identifiers, literals, and data types against the database that will run the file. The generated statements are not a guarantee of portability between all database engines.

SQL — MERGE / upsert: a template based on the schema

This option differs from the two row-based SQL exports. It reads the source structure and creates a parameterized command, with parameters corresponding to columns. It does not write one populated upsert statement for each record.

The syntax follows the source connection's database dialect. For the engines used in these articles, the reviewed implementation selects:

Use the template as a starting point for an application command: review its key, bind the parameters, and adapt it to the destination and execution context. A WHERE filter does not embed a filtered dataset into this template, because the generator does not read data rows. To transfer actual records with upsert behavior, configure the Synchronize tab or a Sync job instead.

8. Export a record selection: key IN and key-list CSV

SQL — key IN (...)

This format exports the selected key values as a predicate:

id IN (1, 2, 3)

It is a SQL fragment, not a complete SELECT statement. You can incorporate it into a query on a compatible database:

SELECT id, sku
FROM item
WHERE id IN (1, 2, 3);

Use it for a small selection of records. Very large IN lists can encounter statement-size or engine-specific limits; a staging table or an importable key list is often more manageable. String keys are written as SQL literals rather than bare numbers.

CSV — key list

This option writes a one-column CSV file, including the key column's header:

id
1
2
3

It is useful when another process needs the selected identifiers but not names, prices, or other attributes. Apply the WHERE filter first to define the selection. Key-only output reduces the columns exported, but identifiers can still be sensitive in a real dataset.

9. Filters, object names, and obfuscation

Enable WHERE filter and enter a condition written for the source database, such as:

id <= 100

Enter the predicate without another WHERE keyword. The source data is filtered before the row-based output is written. To choose a different column projection or construct a joined dataset, use the query source option and return a suitable unique key.

When Target object appears, review it after changing the source or format. It supplies names such as the SQL table, SQLite table, XML row element, or worksheet title. It is separate from the output filename and does not select another connection. Some formats need a meaningful object name when the source is a query.

Obfuscate values (except keys and foreign keys) transforms the output rather than updating the source. For a table or view, the reviewed scope excludes the selected key plus primary and foreign keys reported by the provider. Arbitrary query results do not provide the same foreign-key metadata, so check how their columns are handled.

Obfuscation is useful for preparing samples, but it is not file encryption. Inspect the actual output before sharing it, including preserved identifiers, free text, and generated artifact headers. For the demonstration in this article, the data is synthetic and the option remains off.

10. Reuse the configuration as an Export job

For repeatable JSON extraction, the accompanying example job uses the saved MASTER profile:

{
  "nome": "export-demo-items-json",
  "tipo": "Export",
  "origem": {
    "environment": "article",
    "db": "MASTER",
    "type": "TABLE",
    "object": "item",
    "key": "id"
  },
  "directory": "C:\\dbSliceDemo\\exports",
  "file": "items.json",
  "format": "JSON",
  "pageSize": 10000,
  "ofuscar": false,
  "alertemail": false
}

The property names follow dbSlice's job schema. The file contains profile references and export settings, without connection credentials. Adjust the environment, profile name, and output folder to match your installation. Load it in CLI jobs, inspect the settings, and use Run now or Copy CLI command to obtain the command for that installation.

This JSON job definition was validated without connecting to a database or running another export. GUI and CLI format support should be checked separately: in the reviewed CLI parser, the SQLite database and MERGE / upsert options from this dropdown are not accepted as Export format names. Use the GUI for those two workflows in this guide.

11. Check the output before handing it off

Start with the completion status and row count. For the unfiltered example, expect 11,172 records; for a filtered export, compare against the same predicate in the source. Counting text lines is not a reliable record count for quoted CSV or formatted JSON.

For the demonstration's JSON array, this PowerShell check reads the completed file:

$exportPath = 'C:\dbSliceDemo\exports\items.json'
$exportRows = @(Get-Content -LiteralPath $exportPath -Raw | ConvertFrom-Json)
$exportRows.Count
$exportRows | Select-Object -First 3 id, sku, unit_price

This check loads the file into memory and is intended for the 11,172-row example. Validate nulls, special characters, dates, numeric values, and identifiers against a few known source records. For SQLite, query the generated table; for SQL, review the script before executing it in the intended database.

Use a stable source dataset when you need an internally consistent extract. Paging alone is not a guarantee of a point-in-time snapshot if other processes are changing records while the export runs.

Choose a fresh output filename for each retained result. Existing output files can be overwritten, and cancelling an operation does not restore an earlier file. If an export fails or is cancelled, inspect the destination before treating it as a completed artifact.

With those checks complete, select the format that matches the consumer: JSON for structured application data, CSV for a flat interchange, Excel for interactive review, SQLite for local SQL queries, and SQL or key-only output for a more targeted database workflow.

References and demonstration scope

• dbSlice product website — product information and installation entry point.
• Supplied Export screenshots — the dropdown, example configuration, and reported JSON result.
• Accompanying application implementation — Export panel, export operations and writers, obfuscation scope, and job parser, reviewed for this guide.

The reported export result comes from the supplied demonstration. The other format examples are explanatory excerpts; this article does not claim that every format was executed or benchmarked in that run. No live server address, password, or personal account path is included in the publication files.