Products indiPDF indiAccounting indiBudget All Products Company Blog About Download

indiDatabase Documentation

Complete user guide for indiDatabase — the desktop database for Linux and Windows, in the tradition of FileMaker Pro and Lotus Approach.

1. Getting Started

indiDatabase is a desktop database application in the tradition of FileMaker Pro and Lotus Approach: you design tables, draw forms, save finds, and print reports — without writing a program. Everything lives in one .idb file on your own computer. There is no account, no cloud, and no subscription.

On first launch you'll be asked to read and agree to the license agreement — once per database file — and a new, empty database opens on the Schema screen, because a new database has nothing else to show yet.

Recommended First Steps

  1. Create your first table and its fields under Schema — and every table after it with New table…, which sits under Tables in the sidebar.
  2. Add a few records in Browse — the grid appears in the sidebar as soon as the table exists.
  3. If you're coming from another system, use Import to bring in CSV or legacy dBase files.
  4. Draw a form (Design a form…) once the fields have settled.

New, Open and Recent

One file per business is the natural way to use indiDatabase — the shop's records in one .idb, the club's in another. Click the database's name at the bottom of the sidebar to reach the Databases screen. It shows which file is open and where it is, the files you opened lately (most recent first, with any that have since been moved or unplugged marked Not found), an Open a database… button, and a New database box: type a name, choose where to keep the file, and the new, empty database opens on Schema.

Ctrl+O (⌘O on a Mac) puts the Open dialog up from anywhere; Ctrl+Shift+N starts a new database. Opening another file leaves the current one exactly as it is — every save has already gone to disk. A file you no longer want listed can be taken off the recent list with the × beside it; the file itself is not touched. Double-clicking an .idb file in your file manager opens it in indiDatabase too.

The 30-day trial is the full product. Every feature is on, including sharing. A quiet strip at the top counts the days, so the end of the trial is never a surprise — and when it ends, your database stays readable, printable, and exportable forever. See Licensing.

Back to top

2. The Interface

Apps

A business's database usually does several jobs — invoicing, the mailing list, equipment loans — and each is a few tables, forms and reports that belong together. An app is that group with a name. The switcher at the top of the sidebar shows which app you are in; click it to pick another — All tables first, then your apps in the order you put them. The sidebar then lists only that app's tables, in the app's own order, and Home shows only that app's pinned reports and worksheets, so switching apps feels like switching programs.

An app is a way of looking at the database, never a wall through it. A table can be in more than one app — Customers belongs to invoicing and to the mailing list — relationships work across apps, and users, permissions, sharing and backups cover the whole file. If you open a table the current app does not show (a button on a form takes you there, say), the window follows it into an app that does, or to All tables. Searching the sidebar says when tables match in other apps.

Picking an app takes you to its first table, unless you are already on one of its tables or on Home, which redraws for the app by itself. Manage apps…, the button under the switcher, opens the Apps screen, where you make an app by naming it and ticking the tables it shows, rename it, change its tables, put the apps in the order you want them in the switcher, or delete one — which deletes nothing else. Each template makes an app of its own name, so a database built from templates arrives with its apps ready. A table you make with New table… or bring in with Import while you are in an app joins that app. Which app you are in is remembered on your computer, not in the file, so two desks in the same office can be doing different jobs.

Export… on an app's card saves the app as a template file (.idbt): its tables, fields, rules, joins, forms, reports, saved finds, worksheets, Home pins, and the text styles and highlights they wear — never its records, users or permissions. If the database you open it in already has a text style of the same name, that database keeps its own look. Open it with From a file… at the top of the templates, in this database or another, and the whole app is made again exactly as it was designed. It is how one shop hands a working app to another, or starts next year's database from this year's.

The Three Areas

The indiDatabase window is organised into three areas:

  • Sidebar — Dark navy navigation on the left, generated from the file itself. At the top, once the database has apps, sits the app switcher naming the part of the business you are looking at; beneath it, your tables (that app's, in its order), saved finds, forms, reports (filed in folders), and saved queries. Below them sit Schema, Import, and a collapsible Settings group (General, Users & permissions, Sharing, Backup & restore, License, About). A dot on the folded Settings header shows when the page you're on lives inside it. At the bottom, the database card names the open file and where it is — "On this computer", or the host it's connected to.
  • Header bar — The current table or screen, the record count, and — on a table — the mode switcher: Browse, Find, Summarise, and Preview.
  • Main content — The grid, form, designer, or report at hand.

The Four Modes

Every table can be looked at four ways, and the switcher in the header moves between them: Browse shows and edits records; Find takes criteria and narrows to a found set; Summarise groups and totals; Preview shows the printed page. If the table has a form, the Shown as picker switches the same records between the grid and each form.

Back to top

3. Tables & Fields

Open Schema in the sidebar to design your database: create tables, add fields, rename either, and delete what you no longer need. Every change is checked against the records that already exist before it lands — indiDatabase will not let the schema and the data disagree.

Folders

Within an app — or in a database with many tables — tables can also be filed under folders, the way reports are: on the table in Schema, choose Folder and pick one or type a new one. The sidebar then shows unfiled tables first and each folder as a heading with its tables beneath, and the headings fold and unfold with a click. A folded folder shows a dot when it holds the table you are in, and searching the sidebar opens every folder so nothing is hidden. Folders are for finding your way; for the parts of the business themselves, use apps.

Starting from a Template

A new database opens on Schema with a set of templates to start from — Customer Manager, Inventory, Job / Work Order Manager, Membership Manager, Contacts / CRM, Asset Tracker, Property Manager, Sales / Orders, Parts Catalog, and Donor / Nonprofit Manager. Each is a handful of tables already joined, with the lists a field has to choose from and the totals worked out across the joins. Press Use this template and the tables are made, grouped as an app of the template's name; they are ordinary tables from then on, yours to rename, extend and re-type. Every template hands over a working app, not just the tables: a card form for each table with the related records listed under it, saved finds, grouped reports filed in a folder, a Summarise worksheet, and the useful ones already pinned to Home. The card for each template says what it includes. Everything it makes is ordinary — open the form or the report in its designer and change it. Templates… at the top of Schema offers the same set to a database that already has tables, and From a file… beside them uses a template somebody exported from an app. A template whose table names or app name are already in the database is refused, in a sentence, before anything is made — rename what is there first. Using a template is all or nothing: if anything in it will not fit the database, everything it had made is taken back and the sentence says why, so a template never leaves half an app behind.

Field Types

  • Text — up to a length you choose.
  • Long text — notes and memos, unbounded.
  • Number and Whole number.
  • Exact amount — decimal with fixed places, for money. Arithmetic on exact amounts is exact: a fifth added to 12.50 is 15.00, never 14.999999999999998.
  • Yes or no.
  • Date, Time, and Timestamp.

Each field can additionally be required (a record without it is refused) or no duplicates (two records may not share a value).

Putting Fields in Order

Each field has Move earlier and Move later arrows. The order is the table’s own: the grid, the form designer’s field list and every export follow it. Nothing moves in the file itself, so anything else that opens it is unaffected.

Changing a Field’s Type

Chose Number for a phone number, and now the leading zeros are gone? Choose Change type… on the field. As you pick the new type, indiDatabase says what the change would do before you agree to it — “All 412 values can be kept”, or “312 of 412 values can be kept; 100 cannot be held as dates and would be left empty. For example: ‘March 2024’”. The records stay; every value is converted; anything the new type cannot hold is left empty, exactly as it said.

Anything becomes text without losing a digit. Text becomes a number, a date or yes/no only when it reads as one — “12/03” is not a date here for the same reason it is not one in the grid. A Number field becoming an Exact amount rounds to the places you choose. The change is refused, in words, when the field is required and would lose values, when it allows no duplicates and two values would become the same, or when it carries rules written in the old type — remove those first, change the type, then put them back. A calculated field’s type is its formula’s: change the formula instead.

Changing the schema of a shared database asks you to close it for maintenance first, so nobody is typing into a table while its shape changes. The strip at the top of Schema offers the close and the reopen — see Maintenance Mode.

Back to top

4. Validation Rules

Click Rules… on any field in Schema to say what its values must be: a range ("has to be between 0.00 and 5000.00"), one of a list of choices, and so on. A write that breaks a rule is refused with a sentence about the field — not a constraint name.

  • Rules are stored in the file itself as real constraints, so a record written by any other tool that opens the file is held to the same ones.
  • A rule your records already break is refused when you try to add it — a file cannot honestly hold a constraint its own data violates. Fix the records first, then add the rule.

Back to top

5. Starting Values

Click Starting value on a field to say what a new record begins with — a fixed value ("Missouri"), or today's date. Press New record in Browse and those fields are already filled in.

The starting value lives in the column itself, so a record created by any tool starts the same way. Changing a starting value later leaves existing records exactly as they were: it says what a new record begins as, not what the old ones should have said.

Back to top

6. Calculated Fields

A calculated field is worked out from the record's other fields — Total * 1.2, or Number & " — " & Total — rather than typed into. Add one in Schema by giving the field a formula; the formula is checked as you type, before it can be saved with a mistake in it.

  • Calculated cells refuse to be edited in Browse — there is nothing there to edit. Change an input and the result follows at once.
  • Results are stored as part of the file (generated columns), so anything that opens the file sees the same values, with nothing to recompute.
  • Exact amounts stay exact through arithmetic.
  • A formula cannot ask for today's date — a report printed last week would stop saying what it said. If you want a date, give the field a starting value of today instead.

Back to top

7. Summary Fields

A summary field reads the records at the other end of a relationship and counts, totals, or averages them — an invoice's Invoice total can be the sum of its own lines in another table. Summary fields behave like any other column: sort on them, find on them, print them on reports.

They live in the file (as views), so a line added by any other tool changes the totals everywhere, and the arithmetic on exact amounts is exact: three lines at 7.99, 8.99, and 10.99 come to 27.97.

Back to top

8. Relationships

Define named relationships between tables in Schema — "The customer" from Invoices to Customers, matching on a field pair. Once defined, the relationship is readable everywhere: joined fields on reports, related-record panels on forms, and summary fields.

Multi-Field Joins

A join can match on more than one field pair at once — branch number and state together, say, when branch 17 exists in two states. Files from tools that could only match on one field are full of composite codes typed into the middle of numbers ("B-MO--17-"); indiDatabase matches on every pair instead.

Unique-Together Rules

Schema can also record that no two records may share the same combination of fields — no two branches with the same Number and State. Beyond refusing duplicates (in indiDatabase and in any other tool that opens the file), the rule lets the file prove that a join on those fields lands on exactly one record — which is what allows a report to print a joined field as a column. A join that could reach several records is not offered as a column, because a column showing one of four would be believed.

Back to top

9. Browsing Records

Click a table in the sidebar to browse it. The grid shows the records; type into a cell to edit, and the unsaved-changes bar appears until you save or let the change go. New record adds a row (with starting values filled in), the ✕ at the left of a row deletes it, and Change fields picks which columns show.

A delete happens when you save, and for a few seconds afterwards a dark bar says how many records went and offers Undo (or press Ctrl+Z). Undo puts the records back exactly as they were — same values, same history, same place in every join. It refuses only when something has changed underneath since: a new record has taken the deleted one's place, or its old values would now repeat something the table allows no duplicates of. For anything older than a few minutes, use Backup & restore.

  • Values that break a rule are refused with a sentence when you save, and nothing else in the record is lost.
  • Values a conditional formatting rule matches wear their named style — bold red overdue balances, drawn the same on every desk.
  • On a shared database, a record somebody else is editing says so before you invest anything — see Record Locking.

Back to top

10. Finding Records

Press Find in the header. The grid (or the form) blanks out and takes criteria — a value, a comparison, an "empty" test — per field, across one or several requests. Run it and Browse shows the found set, with a banner saying how many of how many: "20 of 26 records · found by …". You always know when you're looking at a slice of your file.

Ctrl+F (⌘F on a Mac) opens Find on whichever table you are working in, from any of its modes. Ctrl+N (⌘N) starts a new record while you are browsing, and Ctrl+S (⌘S) saves your changes, and F5 or Ctrl+R (⌘R) refreshes the records, and Ctrl+E (⌘E) exports the records on screen to a CSV file. Ctrl+P (⌘P) prints the preview or report on screen; from the records it opens Preview first, so you see the page before it prints. Ctrl+H (⌘H) goes Home from anywhere, and Ctrl+I (⌘I) opens Import, and Ctrl+D (⌘D) opens Schema on the table you are working in, and Ctrl+, (⌘,) opens Settings, and Ctrl+Shift+S (⌘⇧S) opens Sharing, and Ctrl+B (⌘B) opens Backup & restore, and Ctrl+U (⌘U) opens Users & permissions.

Everything downstream works on the found set: Summarise, Export, and reports that run over "the records being browsed".

Saved Finds

A find worth repeating can be saved by name. Saved finds are kept in the file and listed in the sidebar under Finds, one click from the records they describe. All records puts the whole table back.

Back to top

11. Summarise

Press Summarise in the header to group and total without writing anything — query-by-example. Pick a field to group by, pick what to work out (a total, a count, an average of another field), and every distinct value becomes a row with an exact figure. Run a find first and the found set carries in.

  • Keep a worksheet by name and it lives in the file, listed in the sidebar under Queries — opening it brings the grouping back exactly as kept.
  • Pin a kept worksheet and its worked-out table appears on Home, exact figures and all.

Back to top

12. Forms

A form shows one record at a time, laid out the way you drew it. Open Design a form… to place fields, labels, text, boxes, and buttons on a card; once a table has a form, the Shown as picker in Browse switches between the grid and each form, and Previous/Next step through the records.

Press New record while on a form and the card is a new record to type into, with its starting values already filled in and headed "New record 1 of 1 — not saved yet". It sits after the saved records, so Previous walks back to them and Next returns to it; Save makes it a record like any other, and the form rests on it. On a table with nothing in it yet, this is how the first record goes in.

Under the card sits the record's own history — "Added by …", "Changed by …" — the audit trail the engine stamps on every write.

Finding on a Form

Press Find while on a form and the form blanks out: the same boxes now take criteria. This is Lotus Approach's find, and the reason forms and finding are one feature — you search a card by filling in the card.

A form can carry a panel of the records at the other end of a relationship — a customer's card with every invoice raised for them underneath, read across the join rather than copied in. The panel follows as you step through records, and a customer with no invoices says so rather than showing an empty rectangle.

Back to top

13. Buttons & Macros

A button on a form runs a sequence of steps: run a saved find, sort, go to a record, set a field, show all records, export. One press is the whole morning routine — "On account, by name" can find, sort, and land on the first record.

  • A step that sets a field stages the change behind the same unsaved-changes bar typing would — a button is a shortcut through the screens, never a side door past them.
  • A macro can carry one guard: "only go on if Balance > 0". If the test says no, the remaining steps quietly do not run, with a note saying why. Deliberately no branches — two behaviours is two buttons — and deliberately not a scripting language.
  • Every step is checked when the form is saved, so a button cannot be made with a typo in it.

Back to top

14. Named Styles & Conditional Formatting

Named Styles

A style — size, weight, italics, alignment, colour — is defined once, by name, in the form designer's Text styles panel. Form text and report headings wear a style by name: edit "Certificate heading" and every page that wears it follows, because a style is named, not copied.

Conditional Formatting

A field can carry formatting rules: when a formula is true — Balance > 500 — the value wears a named style. Set it in Schema under Formatting…. The condition and the style both live in the file, so every desk draws the same warnings, in the grid and on forms alike.

Back to top

15. Reports

Open Design a report… (or any existing report in the sidebar) to build the printed page: name it, choose its table, paper, and orientation, pick which records it covers — every record, or the records being browsed — and design the layout. The preview beside the designer is the real page, not a sketch of it.

The Six Kinds

  • Lists — columns, grouping, and summaries: group customers by a field and print an exact total and count under each group and at the end.
  • Certificates — one designed page per record, with the record's own values merged into the wording: "This is to certify that {Name} has been a customer since {Account opened}."
  • Labels — N-up label sheets in exact millimetres, flowing across or down, with the Avery presets (5160 and friends) one button away.
  • Letters — one page of flowing prose per record, fields merged into the text, greeting each person by name.
  • Crosstabs — one row per value down, one column per value across, an exact sum where they meet — and an empty cell, not a zero, where nothing happened.
  • Charts — bars, a line, or a pie, with the exact figure printed beside every bar so the picture can be checked.

A list report can also print fields from across a relationship — the customer's name on every invoice line — when the join provably lands on one record.

Questions Asked When It Runs

A report can carry questions — "Opened since?" — that are asked each time it runs. The answer becomes a criterion; a blank answer means "everything", and the page says under its heading what was asked and answered. One report, new dates, no copies.

Folders & Organisation

Reports are filed the way people file reports — by what they're for: "Money", "Mailings", and so on. The sidebar lists them under their folders; the report list can be searched by name and reports refiled without opening them.

Printing

Preview shows the pages; Print… hands the same markup to your operating system's own print dialog, where paper and printer live.

Back to top

16. Home & Pinning

Home, at the top of the sidebar, is the morning picture: the reports and kept worksheets you've pinned, drawn small by the same renderer that prints them. Pin a chart and a crosstab and they're already there when you walk in.

Where the pin is. Save a report in the report designer, and Pin to Home appears beside it in the Reports list. Keep a worksheet in Summarise (the Keep panel on the right), and the same button appears beside it there. Until something has been saved or kept there is nothing to pin, and Home says so and offers both places.

The pins live in the file, so every desk on a shared database walks in to the same picture. Unpin from Home itself, or from where the report or worksheet lives. When the database has apps, Home shows the pins on the tables of the app you are in, so switching apps switches the morning picture too.

Back to top

17. Importing Data

Open Import in the sidebar and point it at a file. indiDatabase reads:

  • CSV and other delimited text.
  • dBase (.dbf) — the format Lotus Approach and a generation of 90s databases kept their records in, including FoxPro-style memo files (even with the Windows-cased filenames they often arrive with).

Coming from Approach, FileMaker or Access

  • Lotus Approach kept its records in .dbf files, and those import directly — point the wizard at each one. The .apr (or older .vew) file beside them holds the forms, reports and joins, not the records; its format was never published, so it cannot be read. Import the .dbf files one after another: after each, the wizard looks for other tables carrying a field of the same name and type — the way Approach joined them — and offers those joins with a tick beside each, so the tables end up joined as they were. Then draw the forms and reports again in the designers — the templates are a quick start for common shapes.
  • FileMaker files (.fp7, .fmp12) cannot be read directly. In FileMaker, show all records and choose File → Export Records…, pick Comma-Separated Text and tick Include field names; then import that file here, one table at a time.
  • Microsoft Access files (.mdb, .accdb) cannot be read directly. In Access, open each table and choose External Data → Export → Text File, delimited by commas with field names in the first row; then import each file here.

If you choose one of those files in the wizard, it says the same thing there and then, with the menu to open.

The wizard shows a preview first: the columns it found, the types it guessed, and sample values. Correct a type or a heading and the preview updates, showing what each correction costs — a column that stops parsing says so before anything is written. The corrected preview is the import: what you approved is exactly what lands.

If the file didn't declare its text encoding, the wizard says the encoding was guessed and shows sample values as evidence. Read a few names with accents before approving — a wrong guess is the failure that doesn't announce itself.

Back to top

18. Exporting Data

Press Export… in Browse and indiDatabase writes the found set — the records the screen is showing, in its sort — to CSV. Run a find first to export a slice; show all records to export everything. A button step can export too.

The file is exact and portable: UTF-8 with a byte-order mark so Excel reads the encoding, amounts as their exact written values, dates as ISO, and quoting only where CSV requires it. Because it's the same query the grid reads (never a scrape of the page), it works at any size.

Back to top

19. Sharing with the Office

indiDatabase shares a database from the app itself — no server product. The computer with the file open is the host; open Settings → Sharing and press Start sharing, and the database answers on your local network. The file never leaves the host machine; everyone else connects to it. (Sharing requires the Multi-User license once the trial ends.)

Pairing Another Computer

  1. On the host, press Add a computer…. A short code appears — it works once, expires in five minutes, and is spent by three wrong tries.
  2. On the other computer, the shared database appears under Shared databases near you (discovered on the local network). Press Pair… and type the code — case, dashes, and spaces don't matter.
  3. Check that both screens show the same fingerprint — it's written in groups so two people can read it to each other across a room.
  4. Sign in with the user account the host's administrator made for you, and the window takes its seat: everything from there on — forms, reports, finds, even importing — is the host's database, live.

The code does more than admit you: it authenticates the host's certificate. An impostor machine advertising the same database name fails even if you type the right code, and the connection is TLS-encrypted and pinned to that host from then on. Paired hosts are remembered (in your operating system's keychain), so a paired desk reconnects without re-pairing.

Live Updates

The host pushes news of every save. Each desk's screens refresh within a beat — the grid tints the row where somebody's change landed, a deleted record is said in words, and your own half-typed edits stay exactly where they are. On a form, the card says "This record was changed by somebody else just now" rather than silently becoming a different record.

Record Locking

When somebody starts editing a record, other desks see a quiet badge — "Ida is editing this record" — and typing into it is refused up front, with her name, before anything is invested. The lock clears when she finishes.

When Two People Edit Anyway

If you and a colleague both edited the same record, your save is not silently merged and not silently lost: a panel lays the two versions side by side, theirs named, yours held. Take theirs field by field, keep yours (re-staged against the record as it now stands), or take all of theirs. The file never holds a mix nobody asked for.

Maintenance Mode

Schema work needs the database to yourself. Close for maintenance — from the strip at the top of Schema, or Settings — puts an amber sign over every desk, in words, with your name on it. Unsaved edits are held, not lost; when you reopen, the sign comes down and the same Save goes through. If somebody is still editing when you close, the confirmation names them rather than silently taking the database from under them.

Dropbox and network drives are not sharing. Opening a database on a synced folder or a network drive is refused, with the reason: those paths corrupt shared databases. Built-in sharing is the safe way for several people to work in one file — the refusal points you to it.

Back to top

20. Users & Permissions

Open Settings → Users & permissions to manage who can do what. Users have accounts and roles; each role carries grants per table — read, create, update, delete — and administrators manage the schema and the people. A desk that may only read is told so in words when it tries more, and enrolled devices are listed per computer.

Grant an app… sets every table in an app at once — see only; see, add and change; everything; or nothing — so "the invoicing clerk gets invoicing" is one action rather than a row of ticks per table. The grants are still per table underneath: the rows below show exactly what landed, each table keeps its own record filter and field access, and a table in two apps has whichever was granted last.

Record-Level Security

A role's grant on a table can carry a record filter — "only records where Balance > 0" — written in the same formula language as everything else and checked as it is typed. The filter is enforced by the engine on every read: browse, count, find, export, report, and query alike. It is not painted over in the interface; a filtered desk simply has a smaller table.

Field-Level Security

Press Fields… on a grant for the field-level half: a field can be hidden from a role entirely — for them it is not in the table, so it cannot be found on, sorted by, or printed either — or shown but read-only.

The Audit Trail

The engine stamps every record with who created it and who last changed it, and when. The stamps ride on the row itself — visible on the form as the record's history — and no screen or tool path skips them, because the engine writes them, not the interface.

Back to top

21. Backup & Restore

Open Settings → Backup & restore. indiDatabase snapshots the database on a schedule, safely, while the file is in use — a backup is a consistent copy, never a torn one. The screen lists your restore points and the backup status: how many snapshots, the latest, and any failures with their reason in words.

  • Restoring stages the chosen point; it applies at the next open, and the window reports on screen that the database is now an older copy of itself — a banner nobody can miss, not a log line nobody reads.
  • If the backup destination is unreachable, the screen says so with the error — it never renders "there are no backups" when the truth is "the bucket didn't answer".
  • Backups living on the same disk as the database are flagged: a disk that dies takes both.

Back to top

22. Licensing

indiDatabase starts as a 30-day free trial of the full product — every feature on, sharing included, no credit card. A quiet strip counts the days from day one, so the end is never a cliff.

When the Trial Ends

Your database becomes read-only — never locked away. Every screen opens, every report runs, every export works, forever. Saving changes is the one thing that asks for a license, in one sentence. Your data remains yours under every circumstance.

The Two Licenses

  • Single-User ($199, one-time) — the whole application on one computer.
  • Multi-User ($399, one-time) — everything, plus sharing on your own network, on every computer in the office.

Buy from Settings → License (the buttons open your browser), and the key arrives by email. Paste it into the same card and everything switches on — no activation server, no phone-home: the key is verified on your own machine and works offline.

Upgrading

Holding Single-User and outgrowing it? The License card offers Multi-User for the difference — $200, never full price twice. The upgrade issues a replacement key by email; paste it into the paste box on the License card (it stays there even while a key is active, for exactly this moment).

Nothing to Renew

Updates within indiDatabase 1.x are free, and there is nothing to renew — no annual fee, no maintenance plan, no subscription. That's not a promotion; it's how all of our software is priced.

Back to top

23. Installation

Linux

  • DEB (Debian, Ubuntu, Mint): download and install with sudo apt install ./indiDatabase_*_amd64.deb.
  • AppImage: download, mark executable (chmod +x), and run — no installation.

Windows

Download the installer (.exe) and run it. Windows 10 and 11 are supported. The installer, and the application inside it, are code-signed by Indomitus Group LLC, so Windows 11's Smart App Control lets indiDatabase run as it is.

If Windows ever reports that indiDatabase is blocked, install the current version from the download page rather than switching Smart App Control off — once off, it cannot be turned back on without reinstalling Windows.

Your Data

A database is an ordinary file — you choose where it lives when you create it, like a document. Updating the app never touches your databases; an update is a normal reinstall over the existing one.

Keep database files on a local disk. Dropbox-style synced folders and network drives are refused by design — see Sharing for the safe way to work together in one file.

Back to top

24. Updates

When it starts, indiDatabase asks the Indomitus Group downloads site which version is current. If there is a newer one, a quiet green strip across the top says so, shows what is new, and offers Download, which opens the download page in your own browser — nothing is downloaded or installed behind your back. Later puts the strip away until the next start; Skip this version keeps it away until a version after that one exists.

The check is a plain request for a small public file. It carries no account, no license key, no database name, and nothing about your computer. If you would rather it did not happen at all, untick Check when the app starts under Settings → About, where you can also check by hand at any time. When the site cannot be reached, nothing is shown at start; About will say so if you ask.

Updates within a major version are free with a perpetual license (see Licensing).

25. Troubleshooting

Blank or white window on startup (Linux)

Some GPU drivers cause WebKitGTK rendering issues. Try launching with:

WEBKIT_DISABLE_DMABUF_RENDERER=1 indidatabase

"This file is on a synced or network path"

Not an error — a guard. Databases on Dropbox-style folders or network drives get corrupted when sync and writes collide, so indiDatabase refuses to open them there and says where to put the file instead. Move the file to a local disk; if several people need it, use built-in sharing.

A record refuses to be edited, with somebody's name

That person is editing the record right now on another desk — this is record locking doing its job before your typing is lost. The lock clears when they finish; press Refresh or simply try again in a moment.

"Closed for maintenance"

An administrator is changing the database's schema. Your unsaved edits are held, not lost — when the database reopens, the same Save goes through. See Maintenance Mode.

A save is refused after somebody else's save

You and a colleague edited the same record. Nothing was lost: the panel under the bar shows both versions side by side — decide field by field. See When Two People Edit Anyway.

The trial ended and the database is read-only

Everything still opens, prints, and exports — that's the promise, not a malfunction. To save changes again, buy a license under Settings → License and paste the key from your email. See Licensing.

Pairing fails with "do not continue on this network"

The machine that answered does not hold the certificate your code authenticates — either you picked a different machine advertising the same database name, or something on the network is impersonating the host. Check the fingerprint on the host's Sharing screen against the one shown, and pair only when they match.

Imported text shows wrong accents or symbols

The source file didn't declare its encoding and the guess was wrong. Re-run the import and pick the right encoding in the wizard — the sample values update immediately, so you can see the names read correctly before anything is written.

Need More Help?

Visit our support page to report issues or request features.

Back to top