Inspect Legacy JDataStore Files with DbSchema

Borland's JDataStore engine still sits inside legacy JBuilder and Delphi for .NET applications as .jds files. DbSchema connects through the Borland JDBC driver and puts the schema on a diagram — the original development environment stays uninstalled.

Open a .jds file and read its tables, columns, and constraints visually
Extract data with standard SQL — SELECT, INSERT, UPDATE, and DDL over JDBC
Document the schema as the first step of a migration plan
Model the PostgreSQL or SQL Server target next to the JDataStore source

available for

ISO-27001 certified

Free Community Edition No signup required 15-day Architect trial included

Free Download

DbSchema showing the schema of a Borland JDataStore file as a diagram

Trusted by teams at

The IDE Is Long Gone
The .jds Files Remain

JBuilder and the CodeGear toolchain left the market years ago, yet the applications they produced keep running — and their data keeps sitting in JDataStore files that only the original tools could inspect comfortably. Every migration plan opens with the same question: what exactly is in there?

DbSchema answers it from a plain JDBC connection: table definitions land on a diagram, the data is one query away, and the documentation writes itself from the schema.

Inspect, Extract & Plan
from a JDataStore File

Everything a migration needs to know about the source, from one connection.

Run SQL against a JDataStore file in the DbSchema SQL editor

Standard SQL, Straight into the File

The JDBC interface takes SELECT, INSERT, UPDATE, and DDL — extract data for the migration or chase an application query bug, all without the original IDE.

Design the migration target schema next to the JDataStore source

Draw the Target Beside the Source

Design the destination schema on the DbSchema canvas while the JDataStore structure sits in the model next to it — migration mapping with both ends in view.

Generate an HTML schema report from a JDataStore database

The Report the Audit Asked For

Generate an HTML report of tables, column types, and relationships — the formal record a legacy application audit or migration plan begins with.

One File Holds the Data
Another Holds the Design

DbSchema stores the schema as a model file separate from the .jds database itself — editable offline, tracked in version control, and shareable with the team planning the migration.

Browse the JDataStore schema model offline

Design Away from the App

Open the model anywhere — the schema stays browsable after the source file is archived.

A Trail for Every Change

Version the model in Git so the migration's schema decisions are documented as commits.

Read generated SQL statements before running them

Statements Shown, Then Run

Any change you plan is spelled out in SQL for reading before executing.

Bring the reviewed design to each environment

Stage by Stage

Bring the reviewed design to each target environment deliberately, one at a time.

JDataStore Setup: the Driver JAR and the File URL

The driver, dsjdbc.jar, ships with the original JDataStore installation — look in its directory or in an archived Borland or CodeGear product distribution — and registers through DbSchema's driver manager. The driver class is com.borland.datastore.jdbc.DataStoreDriver. Match the driver version to the file format version of the target .jds file; a mismatch is a common source of connection failures with archived drivers.

JDataStore is a local-file engine, so the URL points at the file rather than a server: jdbc:borland:dslocal:/path/to/file.jds. Details are on the JDataStore JDBC driver page.