indiDatabase 1.3: Links to Your Records, a Whole Approach Folder, and Text You Can Read

indiDatabase 1.3 is out today, and it has improvements to both import and how the application looks.

Links to your records

Every record now has an address you can paste anywhere.

Copy link sits on each row of the grid, beside History…, and on a form’s record bar. Copy link to this table is at the top of the table. The link goes on the clipboard, ready to paste into a LibreOffice document, a letter, a note or an e-mail.
Click it there, and indiDatabase comes to the front on that record. It starts if it wasn’t running. If it was, the window you already have goes to the record, and no second copy opens. A link copied on a form opens on that form.
A shared database works too. If the database lives on the office host, the link asks first, naming the database as your computer knows it, then asks you to sign in and takes you to the record.
Renaming doesn’t break it. A link names the database by a permanent identity rather than by its name or where the file is kept. Renaming the database or the table leaves every link working. So does moving the file, once it has been opened from its new place.

A link only takes you somewhere. It never saves, changes or presses anything; a form’s own “when it opens” macro runs as it would on any opening, and that’s all. Unsaved changes are offered for saving first, as they are whenever you leave a table. And a link never guesses:

A record deleted since the link was copied is said to be deleted, with its history a click away.
A record that holds the same number but isn’t the one the link was made for — added later, or in another copy of the file — is said, not opened.
A record your role isn’t allowed to see is refused in the same words as one that isn’t there.

The Windows installer, the .deb, the .rpm and the Flatpak register indidb:// links when they’re installed. An AppImage registers itself the first time you run it, unless you’ve already chosen another program for those links.

Bring in the whole Approach folder

Approach kept every table in its own .dbf file. Until now, that meant importing them one at a time. In 1.3 you choose the folder.

Everything is listed before anything is written. Every .dbf appears with its memo file, its record count and the name its new table will have, which you can change. Upper and lower case don’t matter: CUSTOMER.DBF and customer.dbt go together.
Nothing is left out without a reason. The .apr of forms, reports and macros can’t be read, and the window says so. The data those forms showed is in the .dbf files. Paradox tables are named, with how to export them as dBase or CSV, and so are index files that aren’t needed. A memo file whose table isn’t in the folder is named too.
Every file is checked first. A file that would lose values, or whose memo file was left behind, says so on its row. Review this file opens the usual preview for just that file, then brings you back.
Then it all comes in, one file after another, with a progress line (“Importing 3 of 12: ORDERS.DBF”). Cancel stops after the file in hand, and Import the rest picks up where you stopped. A file that fails keeps its reason and gets Try again, while the others carry on. Nothing from the folder is ever imported into a database other than the one you started in, even if you open another mid-run.

The joins Approach had

Approach joined its tables in the .apr, which can’t be read. But the habit it recorded can: two files joined on a field carried the same field name in both, such as CUSTID in CUSTOMER and in ORDERS.

So once the tables are in, one list offers the joins across the whole set:

Only key-like fields are offered. A customer number or an order number counts; a DATE or NOTES field that every table happens to have doesn’t. Those shared names are listed once, underneath, so nothing goes unsaid.
The records decide which way a join runs. When CUSTID appears in CUSTOMER, ORDERS and PAYMENTS, indiDatabase looks at the data. The table that holds each customer number exactly once is where the joins start, ticked, one to each of the others. Where the records don’t make it clear, the joins are offered unticked, and which way they run is yours to say.
The joins are one-to-many. A .dbf file carries no rule saying a value can’t repeat. So a join drawn from the table that holds each value once also marks that field no duplicates there, and the join reads the way the office thinks of it: each customer has many orders. The new Make unique action does the same for any existing field in the Schema designer. If a value already repeats, it refuses, naming the first repeated value.

A page that tells you what you’ve got

The structure summary opens after an import, and any time from the Schema screen. It lists:

every table and every field, with its type;
the rules that matter: required, no duplicates, a starting value, a range, how a calculated field is worked out;
how many records each table holds;
each join, in a sentence;
the forms, reports, saved queries and macros that belong to each table.

Press Print and it’s laid out for paper, with the database’s name and the date at the top of every page.

For anyone who inherited an application nobody wrote down, this is the documentation it never had. It shows each person what the Schema screen shows them, so a table your role can’t read is named and nothing more.

Text you can read

In Settings → General → Appearance:

Text size goes from 100% to 175%, and everything in the window grows together: the grid, forms, dialogs and the sidebar, so nothing on a form ends up overlapping. Ctrl+= and Ctrl+- change it from anywhere, and Ctrl+0 puts it back.
Stronger text makes hints, labels and counts a darker grey and the smallest text a little larger.
Every text colour in the window now meets a 4.5:1 contrast minimum, and a test keeps it that way.
On Linux, indiDatabase starts from your desktop’s own text scaling setting until you choose a size.

Both settings belong to the computer, not the database, so everyone in the office can have their own.

The second month, handled

As every release does, we ran the new features the way an office does in its second month, and fixed what broke before shipping:

Links that land on the wrong record. A table deleted and made again under the same name now gets a new identifier, so old links say their table is gone instead of opening the new table’s records. A restore never numbers a new record with a number that was already handed out. And every link carries the moment its record was added, so a record that only shares the number is caught.
A form’s opening macro now acts on the record a link names, rather than the record shown for an instant before.
Old DOS code pages (437, 850, 852, 861 and 865) chosen for a dBase or CSV import are now honoured, and the preview names the code page actually used. That applies to one-file imports as well.
Two restores in the same second each keep the file they replaced. Before, the second could write over the first one’s safety copy.

Before you update

1.3 is a free update for everyone on 1.x.

Unlike 1.2, 1.3 doesn’t change the file format: a database opened in 1.3 still opens in 1.2. Copy link needs 1.3 on the computer that shares the database, because that’s where the database’s identity comes from.

Getting it

indiDatabase 1.3 is on our download page for Windows 10 and 11 (code-signed) and Linux (AppImage, .deb and .rpm). macOS is coming later.

Single-user is $199. Multi-user, with every computer in the office, is $399. Upgrade from single-user for the $200 difference, never full price twice. Updates are free for all of 1.x.

Every copy starts with a 30-day free trial with everything turned on, sharing included, and no credit card. If there’s an Approach folder you’ve been meaning to deal with, point indiDatabase at it, print the structure summary, and see what you’ve had all along.

Buy it once. It keeps working.