FileForge Studio Community Edition

Download Free Windows Installer (MSI)

FileForge Studio. Forge complex files into reliable integrations.

FileForge Studio Community Edition is a free Windows file import tool for designing record layouts, defining row indicators, mapping database fields and testing structured files before they reach a production workflow.

FileForge Studio

FileForge Studio creates self-contained .ffs configurations for importing and exporting structured data files. FileForge.Core owns configuration rules, database naming, SQL generation and database-object ownership metadata. The WPF application is a replaceable presentation layer and must not contain domain or SQL-generation logic.

Test Import / Export validation

The shared Test Import / Export workspace reads a selected or generated data file through FileForge.Core. The Studio only selects the file and renders Core's validation result.

Core validates:

• mandatory row indicators and their configured case sensitivity;
• fixed-width record and field lengths;
• delimited field boundaries and configured outer quotation symbols;
• required values and configured non-text logical data types;
• Date and Date/Time values using each field's exact configured .NET format;
• configured end-of-row characters, while accepting physical EOF after the final row; and
• the ordered record hierarchy and every parent-relative occurrence rule.

Invalid physical rows are displayed in red. Valid rows remain uncoloured until the user selects a field in the complete record structure; the corresponding physical value is then highlighted in every valid row of that record type. An unrecognised row is isolated where possible so that validation can recover at the next recognised record instead of needlessly marking the rest of the file invalid.

Test Import does not execute JIT Field Processing or write to the database. The CLI executes configured JIT Field Processing only during an actual database import and uses the returned value in the database import payload. The Import action remains unavailable until the selected data file conforms to the current configuration. It then opens a fresh CLI Preview so the user can construct and copy the import command. Running that command validates the file, deploys the configured provider-specific database objects when the schema does not exist, creates the structured JSON payload from the validated values, and executes the generated Import stored procedure. Community Edition supports the mssql and pgsql providers; the required CLI provider must match the engine saved in the configuration. With -d, an existing schema skips all schema, table and stored-procedure deployment. The CLI closes each database connection when its operation finishes.

PostgreSQL connections accept --ssl-mode disable, allow, prefer, require, verify-ca, or verify-full. The default is prefer. The selected mode is used consistently for the postgres maintenance connection required by -n and for the target database connection.

Use --cert <THUMBPRINT> when PostgreSQL requires a client certificate. FileForge searches every accessible Windows certificate store for the first certificate matching the thumbprint and passes it directly to Npgsql without prevalidating it. The same certificate is used for the postgres maintenance connection and the target database connection. If no certificate is found or the connection rejects it, the CLI reports the certificate, TLS, or PostgreSQL provider failure.

Date fields default to yyyyMMdd, and Date/Time fields default to yyyyMMddHHmmss. The Add Field dialog and Fields grid provide common presets while permitting a custom .NET date format. FileForge.Core validates the format and uses exact invariant-culture parsing. The Studio only captures and displays the configured value. Export uses that same format, so import and export remain deterministic.

The CLI export command requires the .ffs configuration, an output path, a positive Root ID, and an existing database supplied with -d. It executes the existing provider-specific Export stored procedure, rebuilds each physical row through FileForge.Core, and writes UTF-8 text without a byte-order mark. It honours fixed-width padding, configured separators and quotation, indicator-export settings, temporal formats, hierarchy, and record-specific row terminators. It refuses to truncate values or overwrite an existing output file. Export does not accept -n and never creates or deploys database objects.

The Export action collects the current CLI database options, output path and positive Root ID, then runs the CLI export command. After a successful exit, the generated output file is loaded into the same validation grid used by Test Import. The active configuration must be valid and saved because the CLI reads the .ffs file from disk. Studio first looks for the CLI at tools\FileForge.exe beneath the FileForge Studio executable directory. If it is not there, the user is asked to locate the CLI executable; that selection is remembered for the current Studio session.

Community Edition database deployment contract

Every configuration has a stable ConfigurationId and a required, human-readable configuration name. Core normalizes that name once for database use and generates a dedicated schema named FileForgeStudio_<ConfigurationName>. Renaming the physical .ffs file does not rename its database objects.

Table and procedure names remain short and readable inside that dedicated schema:

FileForgeStudio_CustomerConfig.Root
FileForgeStudio_CustomerConfig.FileHeader
FileForgeStudio_CustomerConfig.Import
FileForgeStudio_CustomerConfig.Export

The .ffs file stores the selected database engine and a generated deployment package containing:

• schema creation or schema precondition SQL;
• complete table, key and constraint creation SQL;
• import and export stored-procedure creation SQL;
• a versioned JSON payload contract;
• a complete database-definition hash;
• individual object-definition hashes; and
• engine-specific ownership metadata SQL.

The configuration remains the source of truth. Core regenerates the deployment package whenever the configuration is saved. Generated SQL must never be edited independently and treated as authoritative.

Community Edition ownership metadata

Community Edition has no cloud, Glue or database registry. Ownership is recorded on each generated database object through facilities supplied by the selected database engine:

• MSSQL uses extended properties;
• PostgreSQL uses object comments.

Ownership metadata includes the ConfigurationId, configuration name, schema name, FileForge version, object type and object-definition hash. It is database catalogue metadata. It must never become a column or row in an imported-data table.

Before changing a database, the CLI must inspect the target objects and apply these rules:

1. Create an object only when the target name is unused.
2. Stop when an existing object has no FileForge ownership marker.
3. Stop when the marker belongs to another configuration.
4. Do nothing when ownership and definition hashes match.
5. When an owned table definition changed, show the complete dependency-aware deployment plan and require explicit confirmation.
6. Rename affected tables to timestamped names such as FileHeader_Backup_20260803114530 before creating new empty tables.
7. Never migrate, delete or overwrite backup-table data automatically.

This ownership and replacement behaviour must be explained prominently in the end-user Community Edition documentation before database deployment is released.

JSON stored-procedure contract

Import and export procedures use a versioned JSON document. Contract version 1 has this logical envelope:

{
  "file": {
    "filename": "customer.txt",
    "date": "2026-08-03T11:45:30Z",
    "metadata": {}
  },
  "rows": [
    {
      "rowNumber": 1,
      "parentRowNumber": null,
      "record": "File Header",
      "indicator": "FH",
      "fields": {
        "Batch Number": 123456
      }
    }
  ]
}

Row numbers are transient JSON correlation values. Database primary and foreign keys are generated and resolved inside the database layer; they are not exposed as physical-file values.

record is the exact configured record name. Properties inside fields use the exact configured file-field names, not database-column names. The generated procedure maps those properties to the configured database columns. Text values are JSON strings, integer and decimal values are JSON numbers, Boolean values are JSON Booleans, temporal values are normalized ISO-8601 strings, and an empty optional value is JSON null.

The generated MSSQL and PostgreSQL import procedures validate the contract boundary, insert the Root provenance row, resolve row-number correlations to generated BIGINT keys, and inserts configured record tables in parent-first order inside one transaction. Any unknown record or invalid parent linkage rolls back the entire file import. Their generated export procedures accept a Root ID and return the same structured JSON envelope in deterministic parent-first order. The CLI then reconstructs physical values through Core rather than embedding file formatting rules in SQL.

Credentials: non-negotiable rule

Database credentials, connection strings, access tokens and secrets are never stored in an .ffs file, generated SQL, application settings, logs or recent-value history. Every CLI Preview is a new, short-lived dialog. Closing it clears its connection inputs and generated commands; reopening it requires the user to enter the connection details again.

The preview emits the same discrete database options accepted by the CLI. A copied command may contain a password supplied with --password, so the dialog warns that the copied text is sensitive. FileForge does not retain it, but the operating-system clipboard, shell history or any document into which the user pastes it is outside FileForge's control. Test Export starts the CLI directly without a shell and supplies the argument list produced by FileForge.Core, so the displayed command is not reparsed and no shell history is created.

When a configuration is active, CLI Preview uses and locks the database engine stored in that configuration. Without an active configuration, the user must select MSSQL or PostgreSQL before a command can be generated. That temporary selection does not create or modify a configuration.