The databases other tools left behind

Old servers are a target, not an apology

Modern tools drop old databases because supporting them is unglamorous work. Ananke is verified against DB2 9.5 and SQL Server 2014 through their original drivers. Pre-JDBC-4 jars declare no driver class, so the loader scans them and picks the one that accepts the URL. Metadata reads survive AbstractMethodError, because a driver that predates a JDBC method raises it rather than answering false.

When a connection fails, the failure is diagnosed rather than repeated back at you: undersized Diffie-Hellman keys, TLS versions the JDK has retired, a SID given where a service name was wanted, a port with nothing behind it. Each one comes with the next step.

Two versions of one driver, in the same window

A connection can carry its own driver jars, loaded in their own child-first class loader. The 2008-era Oracle thin driver for the legacy database and the current one for everything else, connected at the same time, in the same application. Most tools have one driver per database type and expect you to pick.

Export is a statement, not a dialog

A dialog is forgotten the moment it closes. A statement is saved with the script and runs again next month, on the next environment, from the same file you reviewed last time.

-- structure, data, or both — written where the script says
EXPORT DDL    > * FROM dbo.tbl_Users
EXPORT INSERT > * FROM dbo.tbl_Users WHERE active = 1 ORDER BY id
EXPORT EXCEL  > * FROM dbo.orders
EXPORT CSV    > id, name FROM dbo.orders

-- follows the foreign keys and takes what the row depends on
EXPORT CASCADE INSERT * FROM dbo.orders WHERE id = 42

Rows are streamed and written as they arrive, so the size of the table is not the size of the memory it needs.

The audit log is a script you can run

Everything that changed something is recorded — one file per connection per day, with the user, the catalog, the outcome and the elapsed time. Not a log format somebody has to parse: results and errors are comments, failed statements are commented out, and a USE marks each change of catalog. The day's work replays against the next environment as it stands.

USE dbNORTHSTAR;

-- 2026-08-08 20:14:27.387  user=reporting  OK  1 row(s) affected  12 ms
UPDATE dbo.tbl_Users SET status = 'A' WHERE id = 5;

-- 2026-08-08 20:14:27.390  user=reporting  FAILED  conflicted with FK_lines_orders
-- DELETE FROM dbo.orders WHERE id = 1

Reads are not recorded. A SELECT changes nothing, and logging every one buries what matters.

An undo, not a warning

"Are you sure?" is not a safety feature — nobody reads it twice. Set an undo limit and the rows are read before anything is written: that answers how many will change, and the same read produces the statements that would put them back. Over the limit, nothing is written until you say so.

Environments carry this as policy. Production defaults to manual commit and to confirmation before any data modification, and tints the connection in the navigator so you can see which one you are typing into.

Two reports for what quietly went wrong

Statements that changed nothing. An UPDATE whose WHERE matched no row is how a migration silently does half its job — no error, no effect, and a line that reads exactly like a success. They are counted and listed, with line numbers, so you find them before the next environment gets the same file.

Comparing two databases writes a script and never runs it. Aligning databases can drop rows, and the only defensible design for that is a script somebody reads first. Missing tables, new columns, widened columns, indexes and foreign keys are written. Narrowing a column, changing its type and dropping anything are reported and never written — each of those can lose data.