My Database Pro

What is My Database Pro?

My Database Pro is an all-in-one mobile tool for creating, browsing and managing databases directly on your phone — with no server required to get started. It combines a full local SQLite database manager, a remote MySQL client, a photo-capable record editor, an SQL console, a multi-tab code editor with a real built-in PHP interpreter, a web browser view, an SSH terminal, an SFTP/FTP file browser for your servers, a QR code and barcode scanner and maker that prints labels on A4, a reader that takes text off a photograph, and AI: a chat for any question, and helpers in SQL Query, the editor and the terminal that write a query, change a page or suggest a command in plain language — all in a single app.

The AI runs on an account of your own. The app carries no API key and sells no access to a model: you sign up with a provider, create a key there and paste it in — or point the app at a model running on your own machine, which costs nothing and never leaves your network. Section 14 says how. Everything else in this list works with no account of any kind.

A database created in the app can also be turned into a fully working website with one tap: the app generates a ready-to-use PHP page that displays your data as searchable, image-rich cards on any web server you own, complete with its own AI search box.

The app is translated into 50 languages, and the language can be chosen independently of the phone's own.

This page covers every screen and feature. It is part of the app rather than a website — My Database Pro › How to (the last button on the tool row) opens it, with no connection needed.

1. The Tool Row

Every screen in the app carries the same row of buttons: Databases, the seven tools and, last, My Database Pro, the app's own page. The buttons never move, so wherever you are, the one you want is under the same thumb. When they do not all fit across the screen the row scrolls sideways, and the next button is cut in half by the edge to show that there is more.

Button	Goes to
Databases	Back into the database you were working in, or out to the database list — see below.
SQL Query	The SQL console, on whichever database you last used it.
AI Chat	A plain AI chat for any question — see section 14. It can be taken off the row in My Database Pro → AI Settings.
Editor	The multi-tab code editor.
Web View	The in-app browser, on the page you last read.
Terminal	The SSH terminal, reconnecting to the last connection.
Servers	Your SFTP and FTP servers — see section 10.
Tools	Scan and create QR codes and barcodes, read text off a picture — see section 15.
My Database Pro	The app's own page (the sliders icon): its settings, backup, help and version — see section 16.

Two things worth knowing

The row moves. Hold a finger on it and drag, the same gesture that reorders the database list, and it docks at the top or at the bottom of the screen — whichever end you let go on. Where you put it is remembered, and every screen follows.
It returns rather than restacks. Pressing Editor while an editor is already open drops back onto that live screen with all its tabs and unsaved text intact, instead of opening a second one on top. The same is true of every tool. That is also why the trip is instant.
It remembers the page you left open — except a tool's settings. Leave a server's folder open in Servers, or How to open on My Database Pro, go to another tool, and the button brings you back to that page. A tool's own settings are the exception: leave Editor, SQL Query, Terminal or Web View Settings for another tool and they close, so the button lands on the tool itself. They save as you change them, so nothing is lost. The Web View always reopens the last page you were reading.
Databases takes you back into your database. Open a database and a table, go to AI Chat or any other tool, and press Databases: you are back in that table's records exactly as you left them — the same search, scrolled to the same place. Press it again, or press it while you are in the database itself, and it goes out to the database list. So from anywhere, two taps on Databases always reach the list.
Each tool's settings are its ⚙. The gear at the end of a screen's title bar opens that screen's own settings: Database Settings on the database list, Table Settings on the tables, Post Settings on a table's records, and so on. The AI's settings are on My Database Pro, because every AI in the app uses them.

The button for the screen you are on is drawn with a filled background — since the row is identical everywhere, that patch of colour is what tells you where you are. A page inside a tool lights that tool: Editor Settings lights Editor, AI Settings lights My Database Pro. Inside a database — its tables, its records and their settings — Databases stays lit until you leave it, and SQL Query opened from inside a database lights both <> and Databases.

The app still opens on the database list, as it always has — and on a table straight away when Table opened at start is set. My Database Pro is where you go for the app itself; it has no ⚙ of its own, because the page is the settings.

Tools — scanning and printing QR codes and barcodes, reading text off a picture — has a section of its own: section 15.

2. Main Screen — Your Databases

The screen the app opens on, and the Databases button on the tool row. It lists every database you have: local SQLite databases (shown with a database icon) and remote MySQL connections (shown with a cloud icon).

Title bar

+ Creates a new local SQLite database, or adds a MySQL connection.
Import Imports from a CSV file, a ZIP archive (database plus its images), or a plain .db SQLite file.
⚙ Database Settings — Choose Image Quality: Ask every time, or always Original, Medium or Low. Set to one of the three, adding pictures to a record no longer asks. The app's own settings are on the My Database Pro page — see section 16.

Managing the list

Long-press and drag a database to reorder the list. That order is used everywhere else too, including the database picker inside SQL Query.
The three-dot menu on each database offers: rename, duplicate, delete, and a password. A MySQL connection has Edit Connection in place of rename. Which table opens automatically at app start is set in Table Settings — see section 3.
The password means two different things, and the menu says which. On a local database it is SQLCipher: the file itself is encrypted and without the password there is nothing to read. On a MySQL connection it is the connection lock — one key over the screens that show your logins, which is section 17 — and the menu says Lock with password and Remove lock there. Both draw the same padlock on the row.
A connection someone gave you can hide its login. A connection added from a connection file that holds the owner's own login (shared hosting) has Rename instead of Edit Connection, so its login is never shown. It goes into your backups only when you have set a Backup password (section 8), which seals it; without one the backup leaves it out and says so. Keep the file either way. A connection file with a MySQL login of its own is edited and backed up like any connection: the server itself limits what that login may do.

A fresh install arrives with three sample databases already unpacked — Chinook (the classic music-store sample, good for practising SQL), Animals (a small picture database that shows what image support looks like) and Products (a small product register — article number, EAN, price, stock, supplier — good for trying barcodes and the columns the app keeps up to date). If one of them could not be unpacked, the app tries it again the next time it starts; once they are all there, a sample you delete stays deleted.

3. Tables Screen

Tapping a database opens its list of tables. From here you can:

Create a new table with + in the title bar; rename, duplicate or delete one from its own three-dot menu, Table Options.
Reorder tables by long-press and drag.
Open any table to view and manage its records.
The title bar has Import (a CSV into this database, the arrow down) and Export Database (the arrow up), next to +. The ⚙ after them is Table Settings.
The <> on the tool row opens SQL Query on the database you are in. The database's name on the line under the title bar is a menu: tapping it switches to another database without going back.

If a database is password-protected, you will be asked for the password before its tables are shown.

Table Settings

Table opened at start — the table the app opens by itself when it starts, from any database.

Thumbnails and Show all posts on open are each table's own, in its Post Settings — see section 4. They used to be set here for every table of the database, with each table able to differ; one switch on two screens was one too many. A table you never changed keeps what the database had.

4. Records (Posts) Screen

Opening a table shows its records. Depending on a setting, records are shown either 100 at a time with paging, or all at once.

Working with records

Add, edit and delete records. Each record is made of text fields (the table's columns) and can also carry one or more attached photos.
Photos can be added from the gallery or straight from the camera. EXIF rotation is corrected automatically, so a photo taken sideways is stored the right way up, and a thumbnail is generated for the list.
Several photos can be picked at once. Thumbnails appear inline; tapping one opens a full-screen viewer with pinch-zoom and swipe between photos.
Hold a photo and move your finger to drag it into a different position.
Hold a photo and let go without moving to select it — it darkens and gets a red tick. While photos are selected, a tap selects or unselects another instead of opening it, so you can pick one, several or all of them. The bar under the photos shows how many are selected: the red bin on the left deletes them all at once, after asking once, and the ✕ on the right cancels. The camera button is hidden while you are selecting, so the bin is never beside it. Selecting works on one record at a time, and moving a photo clears the selection.
Images live in a folder beside the database and are referenced from an image_paths column, so they travel with a ZIP export.
Changing the photos updates the record's date. Adding, removing or reordering one changes a file rather than a column, so the database would otherwise never notice — and a record sorted newest-first has to move when its pictures change. If the table has an updated_at column, or a MySQL column that updates its own timestamp, the app stamps it — and does the same when a record is added or a cell is edited.

What a card shows

A card draws the columns you chose, in the table's column order. Both are on Post Settings → Columns: each row has an eye — press it and that column is off the card, press it again and it is back — and the grip that moves it.

The two buttons the card draws in its own corners each have a switch in Post Settings: Add image button (the camera that adds a picture to the record) and Delete button (the ✕ that deletes it). A table you add to but never prune can keep the camera and lose the ✕; one that is only read can lose both.
It is kept per table on this phone, beside the other things about the record list, and it follows a table rename, a duplicate and a backup.

What you can do with a picture

Tap a thumbnail and the picture opens full screen. The ⋮ in the corner there is the way back out of the app with it — for a long time there was none, and a photograph put into a record was a photograph that could not leave it.

Share — the phone's own share sheet: a message, mail, another app.
Save to Device — saves it where you choose, and a .jpg lands in the gallery's own listing rather than among files nothing knows what to do with.
Send to a server — the same two questions every upload asks, which server and which folder, and the same progress bar.

All three work the same on a MySQL record, where the picture is on the server: it is fetched first, used, and the fetched copy is tidied away afterwards. Your own photograph on the phone is never moved or renamed — only copied.

Filling a field without typing

Two readers are offered on every box you can type in — when you edit a cell, and in the add-a-record dialog, where several fields are filled at once. Each offers the camera or a picture already on the phone, the same two words the record's photos use.

Scan a code. A QR square, an EAN or UPC barcode, Code 128 — whatever the scanner recognises — and the value it holds goes into the box. It is offered on every field, not just one called something in particular: a code is an ordinary value once it has been read, and copying one off a label by hand is the thing worth avoiding.
Read text off a photograph. Point it at a label and the app lists the lines it found; pick the one you took the photograph for. All of it is the first row when you want the whole thing. A single line goes straight in without asking.
A picture already on the record is a third place to read from. The label is very often photographed into the record already, and going back to the camera to read it is photographing the same thing twice. That row is offered only on a record that has pictures — the add-a-record dialog has no record yet, so it does not.

A reading is added, never put in place of what is there. It goes in at the caret and on a line of its own, so a box holding Data and a scan of maliki comes back as the two of them, one per line, rather than as Datamaliki. Read into an empty box it is just the reading.

Camera or gallery is one sheet, and its rows can be dragged. Hold a row and move it: the one you reach for lands at the top and stays there. Each sheet keeps its own order, because they are different decisions — a code reader is answered with the camera almost every time, and "add a picture" almost never is.

Both read into the box, never into the row. Nothing is saved until you press Save, exactly as if you had typed it — so a code that scanned wrongly is one you can correct or throw away, and a QR square holding a few thousand characters cannot write itself into your table.

Codes drawn from a column

Beside those two there are two more, and they work the other way round: they take what is in the field and draw it.

Barcode — EAN-13 or EAN-8 when the value is one, Code 128 otherwise. A shelf label: a scanner at a till, a number read at arm's length.
QR code — holds far more and is read by any phone, which is what a link, an address or a whole line of text wants.

The app never guesses which you want: the same article number is a fair answer to both, and which one is wanted is a question about the table. From the picture either one shows you:

Show on card — shows the code under that value on this record's card, and no other, so a shelf label or a serial number can be scanned straight off the screen. Tap the code on the card and it can come off again. Kept on this phone, per table; it follows a column rename and a table rename, and goes when the record is deleted. It also shows on the database's web page (see Publish to Web) the next time the page is sent.
Add as image — attaches a PNG of the barcode to this record's photos, where it travels with the record like any other picture.

Show on card stores no picture. Flutter draws the code from the cell's text every time the row is drawn, so correcting the value corrects the code with it. One code under a value, not two — picking the other kind replaces it, because two stacked under one cell is a card nobody can read. Black on white whatever the theme — a scanner does not read a dark mode. A value nothing can be encoded from says so rather than drawing something a scanner would refuse.

Every QR is drawn with 15% error correction, not the 7% that would fit more in. These end up on labels in corridors, where a code is scuffed and rubbed at for years — and 2331 bytes is far more room than one record needs. One whole record of a real printer table measured 154 bytes, so fifteen of them would still fit in one square.

The cell editor is a list of rows, not a strip of icons. Scan a QR code or barcode, Read text from a picture, Create a QR code, Create a barcode — the same names and icons as on the Tools screen, each with its name beside it, and Cancel and Save at the foot where every other dialog puts them. The two that read into the box come first and the two that draw from it after, which is the order a value moves. The add-a-record dialog has a field per column and often a dozen of them, so it carries two icons under its title instead — Scan a QR code or barcode and Read text from a picture, acting on the field you are typing in. Only the two that read something in: a barcode is drawn from a value, and in that dialog there is no value yet. Its boxes grow with what is typed into them, up from one line, so a description of three lines is three lines you can see — and a reading off a photograph, which arrives as several, is not hidden in a box one line tall.

Columns the app fills in for you

A column with a fixed list of values is picked from, never typed into. If a MySQL column is declared as an enum, the app shows you its values to choose from. This matters more than it looks: MySQL outside strict mode does not reject a value the list does not have — it silently stores an empty string, and the cell you just filled in comes back blank with nothing saying why.
A column the database maintains is shown but not editable. Any MySQL column set to update its own timestamp, and any column called updated_at, is drawn greyed out and left out of the add-a-record dialog. Anything you typed there would be overwritten on the next edit anyway.

Post Settings — how this table is listed

The ⚙ at the end of the records screen's title bar. Everything on it is about this table alone.

Columns — the table itself: its columns, to add, rename, retype, delete, reorder, and show or hide on the cards. The row says how many the cards show, of how many there are. See Column management below.
Sort by — which column the table is listed by, and in which direction. Per table, because your tables have different columns. Pick a date column and it suggests newest first; that is only a suggestion. The list is not reordered while you are in it — the new order shows the next time you open the table. The published PHP pages follow it too — see section 9. An ORDER BY you type into the <> search still wins; it is the more specific instruction.
Add image button and Delete button — the camera and the ✕ on every card, each switched on its own.
Thumbnails — a switch: pictures on this table's cards, or none. While it is on, Thumbnail size under it sets how big they are, 50% to 300%.
Show all posts on open — a switch: whether opening the table fills the list straight away, or waits for you to search. On a table of a few hundred records with photos, waiting is the faster screen.
Searched columns — which columns the search box looks in. All of them are ticked at first; untick the ones a normal search should skip. Searching 001 in a table of printers finds printer 001 — and also every record with 001 in its id, an outlet number or a description. Untick those columns and the search box looks only in the ones left ticked. The last ticked column cannot be unticked, a column you add later is searched until you untick it, and a column the app fills in itself (updated_at) is never searched and not offered. The <> search is not affected: it looks wherever you tell it to.

Search & sort

The search box finds records with every word you type somewhere in them — in the columns ticked under Searched columns.
The list comes back in the order you set with Sort by in Post Settings — newest first, where that is a date. With nothing set, the rows still come back in a settled order, so paging never shows you one record twice and hides another.
Search with filters: contains, equals, greater/less than, and between.
Sort ascending or descending by any column.
A search can also be written as SQL — the condition and the ordering are taken from what you type and applied to the list, which keeps its own paging and images.
Search results can be exported straight to CSV.

Column management

Post Settings → Columns lists the table's columns. + in its bar adds one; a column's ⋮ renames, retypes or deletes it; hold the grip (═) at the start of a row and drag to move it. On SQLite the first row is STRICT. A column's eye shows or hides it on the cards; a hidden one is drawn dimmed — see What a card shows above.

Column types

The type dropdown offers five, and which five depends on the table:

Ordinary table	STRICT table	Holds
`TEXT`	`TEXT`	Text. The default.
`INTEGER`	`INTEGER`	Whole numbers.
`REAL`	`REAL`	Numbers with decimals.
`BLOB`	`BLOB`	Binary data, stored exactly as given.
`NUMERIC`	—	A number where the value converts, text where it does not.
—	`ANY`	Anything, kept as it was given.

A STRICT table trades NUMERIC for ANY and then enforces the column's type on every write. That is SQLite's own rule rather than the app's. The dropdown switches by itself once a table is STRICT, and turning STRICT on names any column whose type is not allowed rather than failing with a raw database error.

There is no date type. SQLite has none — and it silently accepts any word you write as a type, so DATE is stored as plain text just as BANANA would be. Keep dates in a TEXT column in ISO order (2026-08-27, 2026-08-27 14:30:00) so that sorting and comparing work, or in an INTEGER column as a Unix timestamp. On a MySQL connection it is different: there DATE and DATETIME are real types.

Changing an existing column's type rebuilds the table and copies the values across without a CAST, so what fits is converted and what does not is left alone — 'abc' stays 'abc' rather than turning into 0. The app then tells you how many values did not take the new type. The primary key cannot be retyped: it carries AUTOINCREMENT, which only survives on INTEGER.

5. SQL Query

The SQL console, reachable with <> on the tool row from any screen; inside a database it opens on that database. It has syntax highlighting and takes any statement:

SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE, ...

Results of a SELECT are shown as a paged table, and can be exported.

Two pickers in the title bar

The database picker switches which database the console is pointed at — local files and saved MySQL connections alike, listed in the same order as the main screen.
The table picker next to it rewrites the query box to SELECT * FROM `table`; for the table you choose, which is the quickest way to start looking at something.

Asking the AI for a query

The round light-blue AI button in the bottom right corner opens a chat about the database you are on — a file on the phone or a MySQL server. Ask in your own words: "albums from 1975 by year", "how many tracks has each genre", "why does my query fail". The AI knows this database's tables and columns and sees the query in the box.

When its answer is complete, the query goes straight into the box. It is not run: press Execute when it looks right — a statement that changes data still asks first.
Each query in the chat keeps Apply (put it back in the box) and Run (put it in and execute it).
The button can be turned off in SQL Query's settings.

Your query is kept

A half-written query is not lost when you step away to the Web View or the editor and come back. The text stays in the box until you clear it, saved per database — and per table when the screen was opened on one — so two tables never hand each other the wrong query.

The SQL Query button on the tool row also remembers which database you were last working on and returns you to it. The SQL button inside a database deliberately does not: it opens on its own database and leaves the remembered one alone, so a detour never moves where the tool row comes back to.

6. MySQL Connections

Add a remote MySQL server from the + button on the main screen. Once added, a MySQL connection is browsed exactly like a local database — same tables screen, same records screen, same SQL console — except every statement runs on the remote server.

The fields

The form is in two named groups, because it does two different jobs. MySQL is everything used to dial the database. Pictures is everything reached over HTTP instead — the PHP image API, the folder the photographs sit in, the two published pages, and the server all of that is uploaded through. The connection's name is above both, because it belongs to neither: it never reaches a server.

Field	What it is
Connection name	Whatever you want to call it in the list. It may be the same as a database on the phone — a database's copy on a server can carry the same name; the cloud in front of it tells the two apart, and each keeps its own Sort by, columns and settings. Two connections cannot share a name.
MySQL
Server IP/Host	The MySQL address — `name.duckdns.org` or `srv123.hstgr.io`. Never with `http://` or `https://` in front.
Port	Usually `3306`.
Username / Password	The MySQL account.
Database name	The schema to open.
Use SSL	Encrypts the MySQL connection. Also chooses `https` for the image API, but only when Image API host is empty and the address is an IP.
CA / client certificate, client key	Three optional PEM fields, shown only with Use SSL on. Leave empty for an ordinary public certificate — the app checks it. A server with a certificate of its own, such as Cloud SQL or anything behind a private authority, is best given that authority's certificate in CA certificate. A server that signs its own — a MariaDB at home usually does — is remembered the first time you connect and has to present the same certificate after that; if it ever changes, the app refuses and says so, because that is what something answering in the server's place looks like from here. Opening the connection from the database list then shows Server certificate changed with the remembered and the new fingerprint: Trust new certificate remembers exactly the one shown (behind the connection's lock, if it has one), and every connection to that server works again. Do that only when you expect the change — a host rebuilding or upgrading its server, as Hostinger does now and then — and the fingerprint matches what `openssl s_client -starttls mysql -connect host:3306 \| openssl x509 -noout -fingerprint -sha256` shows on a computer. Deleting the connection and adding it again still works too.
Pictures
Server API key	The key defined in `my_database_api.php` on your web server. Needed for images. Make it a long random string — the file ships with none and refuses every call until you set one, on purpose: anyone who knows the key can write into the pictures folder. Tap my_database_api.php under the key and the app does it for you: it makes a key if there is none, writes it into the file, and puts the file on your paired server, in the folder above `my_database_images/`, or saves it on the phone. A file already on the server keeps its keys, so other phones go on working; only the code under them is updated. The app then calls the address and says whether the key is taken. Save the connection afterwards, or the new key is lost. Users, on the connection's ⋮ menu (behind its lock, if it has one), lists the people who use this database. Add a user asks their name and what they may do: everyone can read, and Add records, Edit records and Delete records are switches (Add and Edit start on). Tables themselves — making, renaming, deleting, their columns — stay yours. They get a picture key of their own: they add photos and delete only the ones they added, or any photo when they may delete records. Where your MySQL login is allowed to create users, they also get a MySQL login of their own whose rights on the server are exactly those switches, so the server itself refuses the rest, whatever program they use. Tap a user to change their rights: for a user with their own login the change is made on the server at once and counts the next time they open the database; no new file is needed. Where your login may not create users (shared hosting with one user per database), their file holds your login, and the app warns before making it: their rights then only hide buttons in the app, so anyone who knows the file's password can read your login out of it and use it with all your rights (phpMyAdmin, any MySQL program). Make it only for someone you would trust with your login; their changed rights reach them only with a new file. Either way, Make connection file gives a small file holding only their connection, protected by a password you tell them separately; shared, it carries the steps. On their phone: the database list's + → Add Connection from File, pick the file, type the password. It is added beside what they have (a connection of the same name asks Replace or Keep both). It is not a backup, and Restore does not read it. When the file holds your login, their phone never shows it: the connection's ⋮ menu has Rename instead of Edit Connection, and their backups carry it only when they have set a Backup password (the backup says so when it leaves it out), so they should keep the file. A file with their own login is theirs to see, edit and back up. The app remembers the folder `my_database_api.php` is in after the first time. A user's window also has Make connection file, to make their file again; the bin removes their login and key. New key for this phone (the circular arrow on your own row) replaces your key everywhere at once — do it after anyone who had your old key no longer should.
Image API host	Optional. Where `my_database_api.php` actually lives, when that is not the MySQL host. Empty, the API is assumed to sit on Server IP/Host — the usual shape. The line under this field is the address the app will really call, whichever of the two fields it was built from. It is shown here and nowhere else: under the MySQL host it would have named a machine that is not in that box.
Image folder	Optional. The folder your pictures sit in under `my_database_images/`. Empty, it is the database name — the usual shape. It exists because shared hosting often forces an account id into the database name (`u123456789_MyDb`), and that name would otherwise stand in every public image URL. The full address is previewed under the field.
The two pages	Not fields. `MyDb.php` and `MyDbai.php` as whole addresses: tap either row to copy it, or the globe beside it to open the page in the app's own Web View.
SFTP server	Which of the named servers (the Servers tool) this connection is paired with. It is the one an export offers first, the one a page refresh uploads the database through, and the one that clears the pictures away if you ever delete the connection with them. The picker asks which server, not whether — there is no "None" in it. A connection nobody has paired still reads None on the row, which is the state it is in rather than something anybody chose.

Times read the same wherever your server is. The app puts each MySQL connection on this phone's clock as soon as it connects, so a server running on UTC in a data centre and one under your desk both report a moment in the same words. Nothing already stored is changed — MySQL keeps a TIMESTAMP in UTC and converts it on the way in and out. Note that only TIMESTAMP works this way; a DATETIME column is never converted by anything.

A dropped connection is redialled. Shared hosts hang up on an idle connection within minutes, which used to break a long export halfway through. Now the app simply dials again and repeats the read. Only reads — an insert that reached the server but lost its reply is never sent twice.

Use SSL — and what it changes

With Image API host empty, the Use SSL switch does two things at once. It makes the MySQL connection itself encrypted, and it decides the scheme used to reach the image API:

Use SSL ON   →  https://name.duckdns.org/my_database_api.php
Use SSL OFF  →  http://name.duckdns.org/my_database_api.php

The line under Image API host shows that exact URL as you type, so there is never any doubt about what the app will call. This is also why Server IP/Host takes a bare address: the scheme is the switch's job, and a host typed as https://myserver.org produces https://https://... — which the preview shows you immediately.

Fill Image API host when the PHP file is not on the MySQL machine — Cloud SQL has no PHP, and a shared host's MySQL hostname is not the website. That same preview then follows this value instead:

https://example.com           →  https://example.com/my_database_api.php
https://example.com/my_database_api.php  →  used as typed
192.168.1.115                 →  http://192.168.1.115/my_database_api.php

A value that already has a scheme, or that already ends in .php, is used as typed. A bare address is reached over HTTP: the SSL switch is then only for MySQL's TLS, because a second host is almost always an IP without a certificate.

If the server sends HTTP on to HTTPS, pictures still show but adding, deleting or reordering them fails. The app then says The image server only answers over https and names the address to use — type it into Image API host with https:// in front.

If the PHP file sits on the MySQL host and that server only serves HTTPS, images will not work with Use SSL off. A certificate is issued for a name, not for an IP address, which is why a hostname is the better thing to put in Server host for a public server that also serves the API.

Certificates

With Use SSL on, three optional fields appear: CA certificate, client certificate and client key, each in PEM form. A folder button beside each one picks the file from the phone. Leave them empty for an ordinary public certificate; fill them in when your server expects a private CA or client authentication.

Images on MySQL

A local database keeps its images in a folder on the phone. A MySQL database cannot — so image folders live on your web server and are managed through my_database_api.php, using the API key from the connection dialog. Creating, renaming and duplicating a table keeps its image folder in step. Dropping one does not delete its pictures on the server — a photograph is the one thing no restore can invent, and the folder is yours to clear out when you mean to (Files on a server, the terminal, or your host's file manager). On the phone, where the folder is inside the app's own storage and nothing else can reach it, dropping a table does take its pictures with it. If the API key is missing, the app says so on entry: the database still works, but image features will not.

7. Import & Export

Export is a short wizard — the sheet tells you which step you are on, and Back returns to the previous one rather than cancelling everything.

Step 1 — Format

Format	What you get
ZIP archive	The SQLite file plus a folder of every attached image.
Folder (all files)	The same content as loose files rather than one archive: `.db`, images, `.sql` and `.php`.
SQLite database	Just the raw `.db` file.
MySQL dump	A `.sql` script that recreates the data on a MySQL server.
PHP viewer	A ready-to-host PHP web page — see section 9.
CSV table	One CSV file per table; opens in any spreadsheet app.

Step 2 — Destination

Destination	Where it goes
Copy to MySQL server	A database on the phone only, and first on the list. Not a file: the database is made a MySQL database on a server one of your saved logins reaches, its pictures go with it, and a connection to it is added to the database list. It asks which server, then fills in the connection form for you to check. The connection is given the phone database's own name.
Save to Device	The phone's own Save dialog: you choose the folder and the name there. It reaches anywhere the phone can see — internal storage, an SD card, Drive, another app's folder — and needs no permission at all.
Share	Handed to any other app — email, chat, cloud drive.
Upload to server	Uploaded to your server as a single file, into its Remote Directory.
Update on server	The whole set — database, images and the generated PHP viewer — into a folder on your own web server in one step. With Folder (all files) or MySQL dump it also writes the dump into the saved MySQL connection whose database has the name you give in step 3 (on Hostinger also `u123456_Name`): every table's rows on the server are replaced by the phone's. Formerly "Update on server".

Step 3 — Name

The file name is checked before anything is written. Characters that cause trouble on Android, on Windows or in a remote path are replaced with _; database exports are stricter still, because the name also ends up in the PHP viewer's URL. A name that is already taken is the system dialog's business — it numbers the new one — so the app no longer asks you about overwriting anything.

There is no size limit on an export. Everything is written and read a buffer at a time rather than held in memory, so a database with a few hundred megabytes of photographs saves exactly like a small one.

Import from...

A ZIP previously created by the app (database + images).
A plain .db SQLite file.
A CSV file — a new table is created from its header row. You are asked which delimiter the file uses, so semicolon-separated exports from European spreadsheets import correctly.

A name already on the phone is asked about. Import a MyDb while you already have one and you are offered Replace or Keep both — kept, the incoming one lands as MyDb_1 and yours is untouched. Nothing is ever merged into an existing database: the two sets of images would end up in one folder, beside a database that knows nothing about half of them.

MySQL connections can be exported too, but have no "Update on server" option — a database that already lives on a server has no reason to be uploaded back to itself.

8. Backup & Restore

An export copies one database. A backup copies them all, in one action, into a single file — which is the one worth having before a new phone, a reinstall, or anything that makes you hesitate. Both rows are on the My Database Pro page.

Back up everything

One zip, holding four things:

Every local database — the .db file, its write-ahead log, and the images beside it, folder for folder.
That database's settings — which columns the record list shows (and whether the card's two corners are drawn), which column each table is sorted by, how the record list is drawn, and which records show a code on their card.
Your saved logins, as connections.json: MySQL connections, the named SFTP/FTP servers, the SSH terminal connections, and one API key per AI provider.
Your saved pages and your list order — the Web View's bookmarks, and the order you dragged the database list and each database's tables into.
Your terminal hints, when you have edited them.

It goes wherever an export can — Save to Device, Share, or an upload to a saved server.
The name it suggests puts the date first — 2026-09-12_MDbackup.zip. A file list cuts off the end of a name, and the end is where the date used to be, so every backup on the phone read as the same word. Turned round it survives being cut, and sorting by name is sorting by date.
It never asks for a password. A locked database is copied as the encrypted file it is, and comes back needing the same password it needed before.
There is no size limit. The file is written a buffer at a time rather than assembled in memory, so a phone full of photographs backs up like any other.

The zip itself is the secret. Your logins are written into it in the clear, and that is deliberate: the stored form is encrypted under a key that cannot leave this phone, so a copy of it would open on no other device — written out plainly, it actually restores. Treat the file the way you would treat a sheet of paper with your passwords on it. Two things are deliberately left out: your database passwords, because a backup that could open its own encrypted files would not be worth much, and the Puter token, which is fetched again from the API key that is in the zip.

A backup password seals the logins. My Database Pro → Backup password. Once it is set, Back up everything asks for it before anything else, and the logins and the terminal hints go into the zip encrypted with it (AES-256) — unzipped, they are unreadable. The databases and pictures stay ordinary files. A restore asks for the same password; press Cancel there and everything comes back except the logins. Somebody you lend the phone to therefore cannot send themselves your passwords through a backup. Forget the password, and the logins in that backup are lost — the rest is not.

Restore from a backup

It first asks where the backup is: this phone, or a server — in which case it browses a saved server and fetches the zip for you. Everything after that is the same either way.
Then it asks which of two restores — every time, before anything is written.

Add to this phone

Nothing here is removed. A database whose name is also in the backup is kept beside the one here, as name_1, with its settings and its place in the list following it.
Logins and saved pages merge. A login is matched by name and a page by its address, so a page you renamed on one phone is still the same page. Anything already here is updated, anything new is added, anything the backup does not mention is left alone — and a restored page keeps its place rather than jumping to the end.
The order on your screen wins; anything the backup knows about that you do not is appended.

Replace everything

This phone becomes the backup. Use it to make a second phone match the first — which is what it is for, and what merging could never do: restoring a four-server backup onto a phone that had its own servers used to leave you with seven.

Every local database here is deleted and the backup's put in their place. The logins, servers, saved pages, list order and pairings are written over what is here rather than merged into it.
Anything not in the backup is gone for good — databases included. The confirmation tells you how many databases are here and how many are in the backup before you choose.
A section the backup does not carry at all is still left alone. An older zip simply has no such part, and "match the backup" cannot sensibly mean "delete the things this backup was written before".

Neither choice ever merges into a database that is already here. Your rows are never mixed with a backup's.

9. Publish to Web (PHP Viewer)

One of the app's signature features: turning any database into a real website with a single tap, no web-development knowledge needed.

Update on server (or the "PHP viewer" export) creates two ready-made PHP pages named after the database, sitting next to the .db file on your web server: MyDb.php and MyDbai.php.
MyDb.php is the plain reader — the whole database as cards with photos, a search box, and Print / Save as PDF. It holds no API keys, so it is the one to share.
MyDbai.php is the same page plus the AI search and the SQL box. It is the only one that uses AI keys, and it ships with them empty. To use OpenRouter, Mistral or Claude, open MyDbai.php on your server and paste your key between the quotes at the top:
```
$openrouterApiKey = 'sk-or-v1-...';
$mistralApiKey    = '...';
$claudeApiKey     = 'sk-ant-api03-...';
```
Publishing the page again from the app writes the empty copy back, so paste the key again after that. Ollama needs no key. Without a key the AI box simply says none is set. The SQL box on this page runs one read-only statement at a time and nothing else, whatever it is dressed up as.
Each table is listed in the order you chose with Sort by in the app. The choice goes up beside the database as MyDb_sort.json. With no choice, or a column that no longer exists, the page shows the rows as they are stored.
A page for a MySQL database keeps itself up to date. When you change something on the server through the app — a record, a table, a statement in SQL Query — the app sends the page a fresh copy of the database a few seconds after you stop, and does the same after you leave Sort by. It only does this where the page already is: the connection's paired server, in its Image folder. Changes made outside the app (phpMyAdmin, another phone) are not seen until the next change made in the app. Each send is noted in the log (My Database Pro → View log): Web page of LiuServer updated, or not updated with the reason — no server paired, or no page in the folder it looked in.
The page from the app. On a MySQL database's Tables screen, the chain icon at the right end of the line with the database's name opens its page (MyDb.php, not the AI one) in the Web View. A change you have just made is sent first — a spinner stands in for the chain for those few seconds — so the page you see already has it.
Codes on the cards. A value set to Show on card in the app shows its barcode or QR code on the page too, under the same value of the same record. The app draws the codes and sends them beside the database as MyDb_codes.json; the page shows a code only while the cell still holds the value it was drawn from, so a value edited on the page loses its code rather than showing a wrong one.
The AI search box in MyDbai.php searches only that one database — MyDbai.php learns MyDb, Animalsai.php learns Animals — and does not answer general questions. A code or name is turned into SQL on the page; longer questions go to a locally hosted Ollama model (free) or a cloud API. The provider and your own API key are configured by editing a few lines near the top of the generated PHP file — the same rule as in the app: the key is yours, not the app's.
A single switch inside that file, $editing = 'on' or 'off', controls whether visitors are allowed to edit data or only view it.
A password-protected database still works. The page opens its database with plain SQLite and no key, so the upload publishes a decrypted copy — made through the database you already have open, so nothing asks you for the password again. The copy on your phone stays encrypted. Only Update on server does this; an export of the database itself, and the ZIP you can import back, keep their encryption.
The upload also puts an .htaccess beside the page, so a browser cannot download the .db or the .sql directly. The page is meant to be read over the web; the data behind it is not.

Because it is a plain PHP file, the published page can be opened, inspected and customised in this app's own Code Editor — and actually run through the PHP Preview — before it is ever uploaded.

10. Servers — SFTP & FTP

A list of named servers, not one slot. The Servers button on the tool row opens that list; + in its title bar adds one, a row's three-dot menu has Configure, Duplicate and Delete, and tapping a server shows its files. Add as many as you have hosts — a home Mac Mini, a VPS, a shared-hosting account — each with its own name, address and folders.

A server speaks SFTP or plain FTP, and you say which. Most shared web hosting offers FTP on port 21 and no SSH at all, so a host like that can be set up and used exactly like an SFTP one. One thing genuinely differs: over FTP a file counts as changed by its size alone, because there is no dependable way to stamp a date onto what was just uploaded. Over SFTP the app sets the date itself and compares both.

One server, both protocols

A machine you can reach two ways is one entry, not two. The Protocol switch chooses which way is in use, and everything except the name is remembered separately for each — address, username, password, port, and both folders. Flip the switch and the other set comes back exactly as you left it.

That matters because the two are rarely alike:

Hostinger answers FTP on 21 and SFTP on 65002 under different passwords, and its folders are absolute over the one and relative over the other, because SSH lands in your account home.
A Mac Mini is 192.168.1.115 over FTP on your own network and a DuckDNS name over SFTP from outside it — the same machine at two addresses.

Filling in a protocol you have not used yet starts from the address and account already on screen, since most servers answer both in one place; usually only the port and the password need changing.

The switch is a setting, not a question during an export. An upload uses whichever protocol the server is set to right now; to send over the other one, come back here and flip it. There is deliberately no automatic fallback — quietly dropping from SFTP to plaintext FTP is not a decision the app should make for you.

Field	Example	What it is
Name	`My server`	How the server is listed. The name you pick from — two servers may not share one. Lists show the name and SFTP / FTP only; the address is seen only here, in the server's own form.
Protocol	`SFTP`	SFTP or FTP — which one this server is using. Both are saved; see above.
Server IP/Host	`192.168.1.115` `server.duckdns.org`	The bare address, no `http://`.
Port	`22` / `21`	22 for SFTP, 21 for FTP. Checked as you type.
Username / Password	`root`	The server account.
Remote Directory	`/var/www/html/maps/`	Where a plain upload lands.
Upload folder	`/var/www/html/my_database_images/`	Where "Update on server" publishes. Must be writable by your account.

Test connection

On the same form, and worth using before your first upload. It dials, logs in and looks at both folders — using the fields as they stand, not as they were last saved.

It always gives you an answer. A folder that does not exist yet is reported, not treated as a failure, because an upload creates what it needs.
That report is the point. A mistyped /https/maps/ is created just as happily as /htdocs/maps/ — and afterwards nothing tells you your files went somewhere nobody will ever look.
If it cannot connect, the message names the host and the port the app dialled. The raw network error names a local port instead, a number you never typed, which is no help at all.

Which server an upload goes to

A local database and a MySQL connection can each be paired with a server. A connection's pairing you choose, on SFTP server in its form. A local database's you do not: it is written down the first time an upload has to ask you which server to use, and the only place it can be seen afterwards is the Used by line under each server in the Servers tool. Either way, which server an upload actually uses is asked during the export, right after you choose the destination — so the folder shown in the later steps is the folder your file really lands in.

The paired server is ticked, not forced, and picking a different one this time does not change the pairing.
The question is skipped when there is nothing to choose: one saved server is not a menu, and none opens the setup form.
When the upload finishes, the app tells you the full path the file landed at and names any folder it had to create to get there.

A folder upload is a sync, not a blind re-upload: the app scans what is already on the server, sends what changed, skips what did not, and removes files that no longer exist locally. When it finishes it reports how many files were uploaded, skipped, deleted and — if any — failed, so a partial upload is never mistaken for a complete one.

A folder path is always treated as a folder. If you type it without the trailing slash the app adds one, so an upload cannot end up writing a file alongside the folder instead of into it.

Files on a server — Servers

Shows what is actually on a server, and is how you put anything from your phone there — a photo, a PDF, a whole folder. Nothing else here does: every other feature writes into folders it was told about and never reads one back, so a file that landed in the wrong place stayed invisible until a page failed to change.

List folders, upload, download, rename, delete a file, delete an empty folder, make a folder. Deleting a folder is not recursive, and a server that refuses tells you so.
Upload asks one thing — Files (one or several) or A folder (everything in it, subfolders and all) — and puts it in the folder you are looking at. A folder lands in one of its own name: sending Camera while you are in /htdocs/ puts it in /htdocs/Camera/. It all goes on the connection the screen already has, each file fetched only when its turn comes, and a file the phone will not hand over is passed over and counted rather than losing the rest.
You can also start from another app. Share a file to My Database Pro from the Gallery or Files and the app asks which server and which folder, with that file in hand.
Rename is the one thing here that changes a server without destroying or sending anything — a file uploaded under the wrong name used to mean downloading it, deleting it and sending it back up. It works on a folder too. A name already in the listing is refused, and so is a name with a slash in it: that is a move, not a rename.
Uploading over a name that is already there asks first. Neither protocol asks — both overwrite in silence.
Hold a row to see where the file really is, and it is copied at the same time — Copy path is on the row menu too. This screen is the only thing that knows: a row carries a name, and the path is that name under whichever folder you have walked into. Use it before typing a path into the Terminal, or before asking the AI about a file. Folders have a path too, ending in a slash — and the path is shown on screen whether or not the clipboard accepted it.
Look at a picture without leaving the app — View image on the row menu. A text file can be opened in the editor and saved straight back to the server.
Double-tap a file and it does whichever of those two fits: a picture opens in the viewer, a text file in the editor. Both stay on the menu as well, since nothing on a row tells you it can be tapped twice. Download stays on the menu only — it asks where to put the file, and a gesture should not start a conversation.
Back goes up one folder, not off the screen. Only when there is nowhere left to go back to does it close the browser.
It opens on the server's Remote Directory rather than the root — on shared hosting the root is full of folders you did not make and cannot write to.
The browser is also a picker. It is how you choose the folder an upload goes to, and how you find a backup on a server to restore from. In those modes the folders still open, but everything that changes the server — upload, delete, new folder — comes off: a picker is not a place to delete things.

11. Code Editor & PHP Interpreter

A multi-tab code editor with syntax highlighting. Open and save files on the phone, undo/redo, and find and replace within a file.

HTML files get a live Preview.
PHP files get a real Preview: the app ships an actual PHP 8.5 interpreter, with the mysqli and pdo_mysql extensions built in, and runs the file on a small local server on the phone. PHP scripts that connect to a remote MySQL server can be written and tested without leaving the app. (Android only.)
Leaving the editor asks nothing and loses nothing: every tab, unsaved text included, is kept and is there again next time. Each tab keeps its own undo while the app is running, also after a trip to another tool; it starts afresh only when the app itself is closed. Closing a tab with unsaved changes asks first. Tabs with unsaved changes are marked.
Files that are not text are refused rather than opened, since opening one here would corrupt it — and the next Save would write the damage back over your original.
A tab remembers where you had scrolled to; a newly opened one starts at the top.
Opening an .html or .php file on the phone asks whether to open its folder too. Android lets the app see only the file you picked, so the folder picker comes up, already in that file's folder — confirm it, and Preview shows the page with its stylesheets, scripts and pictures, and the AI can see and change those files. Only this file opens it alone. A file opened from a server brings its folder by itself.

Asking the AI to change the page

The round light-blue AI button floating in the bottom right corner — the same ✦ as AI on the tool row — opens a chat about the tab on screen. Say what to change — "make the header blue", "add a contact form" — or, in an empty tab, describe the page to make. Close the chat and you are back in the editor as it was. The button can be turned off in the editor's settings, which takes the AI out of the editor.

The AI works on the tab itself: when its answer is complete, the new code goes straight into the editor.
For a change it sends only the lines that change, shown in the chat in red (taken out) and green (put in), so it is quick and leaves the rest of the file alone. A new page comes as the whole file.
Small copying slips — different indentation, plain dashes or quotes for typographic ones, a missing blank line — are forgiven, as long as the change still fits only one place in the file.
If a change cannot be placed exactly where it belongs, your file is left as it was, the AI is shown the lines it missed and sends the change again; only if that fails too is the whole file asked for — you do not have to do anything.
Not what you wanted? Undo takes the whole change back in one tap — or just ask again: it is always sent the file as it is now, with your own edits in it.
Every version it wrote keeps Preview and Apply in the chat, so an earlier one can be put back.
The pencil beside a question puts it back in the box to be changed and asked again, as on the AI screen. The file goes back to how it was when that question was first asked — for a page with its folder, every open file of the folder too, and files the answer made are closed — and everything after it is replaced.
An answer cut off half-way never touches your file.
It uses the provider, model and key picked in AI Settings.

Working on files that live on a server

A .php on a web host is a file to edit, not one to download, change, and upload again by hand.

Open from server in the editor's menu — or Open in editor while browsing a server — opens the file straight off the host.
Save writes it back to where it came from. The tab remembers which server, but never the password, so a server you deleted in the meantime gives you a message rather than a crash.
Opening the same file twice takes you back to the tab already holding it, instead of making a second copy that could overwrite your work.
Upload to server is a third answer to "where does this go", beside Save and Save as. It writes a copy somewhere the tab has no relationship with: your tab keeps its own file and stays unsaved if it was. A file that quietly started saving somewhere else would be the worst kind of surprise.

Editor settings

The editor has its own settings, separate from the app's:

Text — font size, line height, tab size, word wrap, line numbers.
Appearance — the syntax colour theme.
Reminder — whether a date and weekday separator is inserted into reminder.txt at startup.
Auto-opened files — which bundled files open as tabs when the editor starts.

The reminder note

Every time the editor opens, a tab called reminder.txt is ready and waiting — a persistent scratchpad that autosaves to the phone as you type, so it is always there for quick notes.

12. Web View

Opens any web address inside the app — a phpMyAdmin panel, a local web app, the PHP viewer page from section 9, or any page you built in the editor.

Pages can be saved with a friendly name. A long press on the Web View button on the tool row opens that list from any screen.
The globe in the top bar opens a small window of your saved pages beside it, with the page still visible behind. Hold a row and drag to reorder the list — so the page you read every day does not have to stay at the bottom just because you added it last.
The Web View button returns you to the page you were last reading, at the place you were in it — not to the bookmark that started it. That survives the app being closed, or Android reclaiming it in the background.
Back first walks through that page's own history, then returns to where you came from.
Each saved page remembers its own text size (30%–300%, 100% is normal), so a page with tiny text can be made comfortable to read.
A "Block ads" switch blocks requests to the big ad and tracker networks, on by default, and in this view only — it changes nothing outside the app's own browser. It is a hand-picked list, not a subscribed filter list, so it removes most ads but not all; an ad a site serves from its own address cannot be caught by a list of ad domains at all. Turn it off for a page that breaks with it on — a login behind a blocked domain, say.
Blocking also has to close the hole the ad leaves. A site reserves the banner's height in advance and only gives it back once the ad reports itself drawn — which, blocked, never happens, so the page keeps a column of white gaps with spinners turning in them. The app hides those empty slots itself, before the page is drawn.
A brand-new install already comes with a page saved for you: the SQLite Tutorial website, a free reference for learning SQL — a handy companion to SQL Query.

13. SSH Terminal

A full terminal (built on xterm) to any server you manage over SSH. Connections are saved by name, host, port, username and password.

The Terminal button on the tool row reconnects straight to the connection you last used, rather than making you pick it out of the list again; Back still reaches the list underneath. An SSH session cannot truly be resumed — leaving the screen drops the connection — so this reconnects rather than restores.

The server's host key is remembered the first time you reach it, and every connection after that has to present the same one — the same thing an ssh client does with a host it has never met. It is what makes the password you type go to the machine you meant. If a server is genuinely rebuilt its key really does change, and the app will refuse it; deleting the saved connection or server forgets the old key along with everything else kept under its name, and the next connection writes down the new one. The same check covers Files on a server and every upload.

The round light-blue AI button (✦) in the terminal's bottom right corner (it can be turned off in the terminal's settings) asks the AI about what is on the screen — why a command failed, how to find something on the server. It is shown the last lines of the terminal, never your password. A command it suggests has a Paste button that puts it at the prompt; it is not run until you press Enter yourself.

An extra key bar above the keyboard adds the keys a phone keyboard is missing:

CTRL ALT TAB ESC ⌫ / - Home End PgUp PgDn Copy Paste ↑↓←→ OK / Enter

Hold ⌫, ← or → and it repeats, the way a keyboard key does; a tap is still one.

Output text can be selected with on-screen handles for copying, the same way as in the editor. Drag a handle to the top or bottom edge and hold it there, and the text scrolls under it, so a selection longer than the screen needs no second finger.

Hints

The light bulb in the title bar opens your hints: commands you use often, one tap from the prompt. They open as a panel under the key bar, the way the keyboard does, so the terminal shrinks above it and the prompt stays in sight. A tap pastes the command into the prompt and never runs it — press OK to send it. The panel stays open for the next one; close it with ✕ or the bulb.

The hints are one text file, edited whole with the pencil in the panel. A line starting with ### names a hint, and the lines under it are its command:

###Create database Animals
mysql -u root -e "CREATE DATABASE Animals;"

###Import a .sql file from the phone into Animals
mysql -u root Animals < {file}

Save keeps your copy; Reset to default in the menu goes back to the hints the app ships with.

{file} in a command asks for a file. Tapping the hint asks where it is — this phone or a server, the same two answers a restore asks for — sends it to your home folder on the server over the connection you are already on, and pastes the command with {file} replaced by where it landed — for example mysql -u root Animals < ~/Animals.sql — waiting for OK. A file of the same name already there is replaced.

Or the app can write one for you. The third answer is Make one now: pick one of the databases on the phone and the app writes a fresh .sql of it, sends it up and fills the command in — no export, no Save to device, no hunting through Downloads. It is also the only one of the three that is guaranteed current; a dump sitting on a server is whatever the last export left there. Local databases only: dumping a server's database to feed it back into a shell on that same server is not a thing anybody wants.

And it does not ask which database when your command says. A hint reading mysql -u root MyDb < {file} is a hint about MyDb, so Make one now writes MyDb.sql and pastes it — no list to pick from, and no way to send the wrong database to a command naming another. It only does this when your command names exactly one of your databases: naming two, or naming one by accident (a database called root, in mysql -u root MyDb), brings the list back, because then the app has no right answer.

A server is offered because that is often where the file is. A .sql written by an export is as likely to be sitting on a web host as on the phone, and fetching it with something else just to pick it out of Downloads was the way round that. A file taken off a server is still sent up to the home folder rather than named where it lies: there is no telling from the terminal whether that server is this machine — a host answers to several names, and through two different logins — so the app never guesses.

Several lines pasted at once all go to the shell, not into a program the first line starts: mysql -u root followed by a CREATE line does not run the CREATE inside MySQL. Give MySQL the statement on the same line with -e "…".

14. AI Chat Assistant

The ✦ on the tool row is a plain AI chat: ask it anything, in any language, and it answers in the language you wrote in. It also knows how this app works: ask it how to do something here, or where a setting is, and it answers from this guide. It knows nothing of your data: for a query, use the AI button in SQL Query; for a page, the one in the editor; for a server, the one in the terminal.

The bar holds the name and the model in use. To start a new chat, tap the clear-chat button at the right end of the bar (greyed out while there is nothing to clear). Each answer has a Copy button under it that copies the whole answer. While something is typed in the box, the square inside it clears the text.

Provider & model

The API key is yours, and you have to go and get it. The app ships with none and cannot give you one — it is not a service you are buying here. Open an account with the provider you want, create a key on their site, and paste it into API key in My Database Pro → AI Settings. Whatever the model then costs is billed by that provider to that account. Until a key is in, the row says Not set and that provider's models will answer nothing.

Chosen in My Database Pro → AI Settings, which every AI in the app uses — the chat, the editor, the terminal and SQL Query. The key you enter is stored encrypted on your own device, per provider, and never leaves it — it is sent to that provider and to nobody else.
Each choice is saved as you pick it, not on a Save button — so a key you typed and then backed out of is not quietly lost.
The providers shipped with the app are Claude (console.anthropic.com), OpenAI (platform.openai.com), Gemini (Google AI Studio), Grok (x.ai), Mistral (console.mistral.ai), DeepSeek and Puter — each of them somebody you sign up with yourself. Puter is the one that takes either an API key or user:password of your account.
My server has to be your own server. It is an Ollama (or anything else that speaks the OpenAI API) running on a machine you control — a Mac Mini, a PC, a server at home. It needs no key and nothing leaves your own network, which is what makes it the cheapest and the most private of them, and it is also the one that will not work until you set it up.

What ships in that row is an example, not an address that will work for you. It points at a machine on the author's own network (http://10.139.243.1:11434/v1, model qwen2.5-coder:7b), which means nothing from your phone. To use it: install Ollama on your machine, ollama pull a model, let it listen on the network rather than only on localhost, then open My Database Pro → AI Settings → Edit providers (JSON) and put your own address and model name in. A model bigger than that machine's memory is read off the disk a token at a time, so pick one that fits — 7B is comfortable on 8 GB.

Models can be added or removed from the same screen, the whole provider list can be edited as JSON, and both can be reset to the shipped defaults. The shipped model names are examples too: providers retire and rename them, so a name that worked last year may have to be corrected here.
Once you have saved a list of your own it wins over the shipped one, so a later app update will not overwrite your addresses or your keys.

Voice

The microphone button dictates a message.
Recognition uses the phone's own speech engine. The language list is asked of the recogniser directly, so it covers the languages it handles over the network too, not only the ones installed for offline use.
Input language, auto-send after speaking, and reading replies aloud are all configurable.

Other

The pencil icon on an earlier message re-edits it; everything sent after that point is replaced when the edited message is resent.
Code in an answer has a Copy button.

15. Tools — QR Codes, Barcodes & Text

A QR code and barcode scanner, a QR code and barcode maker that prints labels on an A4 page, and a reader that takes the text off a photograph. They work on their own, with no database open; inside a table the same scanner and text reader fill a field for you (section 4).

Codes and text

The button before My Database Pro on the tool row. Four things to do, under Codes and text. Hold a row and drag it to put the one you use most on top; the order is kept.

Scan a QR code or barcode — with the camera or from a picture. What it read is shown, with Copy, and with Create a QR code and Create a barcode, which open the maker with the scanned text already in. That is how a label you already have is printed again — more copies of it, bigger or smaller. Create a barcode is offered only when a barcode can hold the text.
Create a QR code — type any text (a link, a wifi password, an address) and the code is drawn as you type. The count under the box is how much of the 2331 bytes a QR holds you have used. The save icon in the title bar saves the picture (PNG) to the phone, shares it, or sends it to a server.
Create a barcode — the same, on one line. The kind is chosen from what you type: EAN-13 or EAN-8 when the digits are a valid one, check digit and all, otherwise Code 128, which takes letters, digits and signs. Code 128 has no bars for letters such as č, ž, å or €; with one of those in the box the screen says so and will not save. Saved the same three ways as a QR, as barcode.png.
Read text from a picture — the words off a photograph, shown with Copy.

Printing codes on an A4 page

Under the drawn code, both makers show the A4 page it will be printed on:

Size — type the exact size in millimetres, the one that fits where the label goes: 43, 56. For a QR it is the side of the square (15–190 mm); for a barcode it is the width (30–190 mm) and the height is half of it, digits included. − and + change it a millimetre at a time. A size out of range shows the range under the box, and nothing can be printed or saved until it is back in.
Copies — − and +, from one up to as many as fit on the page, shown as "3 of 24". Whole page fills the page, and stays full when you change the size.
The page itself, drawn as it will come out: 10 mm margin, 6 mm between codes (the white a scanner needs around a code, and room for scissors), filled from the top.
Print — Android's own print dialog: pick a printer and print straight away, or pick Save as PDF there. Keep the scale at 100% (not "fit to page"), so 43 mm on the screen is 43 mm on paper.
Save as PDF — the same page as a PDF, saved to the phone, shared, or sent to a server, the same three ways as the picture.

The PDF is drawn in lines, not pixels, so the code is sharp at any size and on any printer. Print and Save as PDF are also icons in the title bar.

Tools remembers the maker you left

Tools remembers the maker you left: go to another tool and come back to Tools, and it opens again with the same text, size and copies. Going back out to the Tools list yourself forgets it. It is remembered while the app is running.

16. My Database Pro (App Settings)

The last button on the tool row, with the sliders icon; the page is titled with the app's name. At the top: the app's icon, what it is and who made it; at the foot, the version and build number — which is how you tell one build from another. In between, the app's settings, grouped. A row with a choice opens a picker; a plain on/off is a switch on the row itself, here and on every settings screen.

Purchase

The app is unlocked with a purchase through Google Play, in one of two ways, and either unlocks everything:

Buy once — unlocks the app for good.
Subscribe — a monthly subscription. Someone who has never subscribed starts with a free trial; cancel it in Google Play before the trial ends and nothing is charged.

Until the app is unlocked, the purchase screen is all it shows. The Purchase row says whether it is Unlocked or Read-only, and opens the purchase screen: Restore purchases asks Google Play again — on a new phone, or after buying on another one with the same Google account — and Manage subscription in Google Play is where a subscription is cancelled.

When a subscription ends the app turns read-only: your databases, on the phone and on your MySQL servers, still open and can be read, Back up everything and Export still work (an export to a server sends the files, but does not load them into a MySQL database), and nothing else does. The tools on the tool row are greyed out, and anything that would change data says Read-only: this needs a subscription, with Unlock to subscribe again. Nothing is deleted.

The app checks with Google Play when it starts and whenever it comes back to the front. Without a connection, a subscription Google Play has confirmed keeps working for 7 days; a one-time purchase keeps working for good.

Preferences

App Language — follow the phone, or pick one of the 50 translations directly.
App appearance — Light Mode, Dark Mode, or System, which follows the phone's own light or dark setting, even when it changes by itself in the evening. System is the default, as it is for the language. Applied instantly.

AI

AI Settings — the provider, model and API key every AI in the app uses, the chat's text size, and voice. See section 14. AI on the tool row there takes the ✦ off the tool row if you have no AI to use; the AI buttons in the editor, the terminal and SQL Query are turned off in each one's own settings.

Backup

Back up everything, Restore from a backup and Backup password. See section 8.

About

How to — this page. It is part of the app rather than a link to a website, so it opens with no connection at all.
Privacy Policy — in the app for the same reason, and it is short: nothing is sent to us, and your data leaves this phone only when you send it somewhere yourself. The one exception is the technical diagnostics Google's code scanner and text reader report to Google, which the policy spells out.
View log — every message the app has shown, kept so one that was on screen for a second can still be read, and copied, afterwards. The last 100 are kept.

This page was Setup, opened from the database list's ⚙. Choose Image Quality is about the databases rather than the app, so it stayed with them: the database list's ⚙ is Database Settings now (section 2). Thumbnails and Show all posts on open are per table, in each table's Post Settings (section 4). Codes and text and the servers are the Tools and Servers buttons on the tool row.

17. Security & Your Data

Database passwords. Setting a password on a database encrypts the whole file, not just the screen in front of it. Without the password the file is unreadable, in the app or out of it.
Saved credentials. SFTP details, MySQL and SSH connections and AI API keys are stored encrypted. On Android the key lives in the hardware-backed Keystore; on Windows the platform's DPAPI is used. The key never leaves the device.
What that means for backups. Because the key cannot leave the device, copying the encrypted values into a backup would only carry over a blob nothing could read. So the backup writes those logins out in the clear instead, which is what makes them actually come back on a new phone — and what makes the backup file itself worth protecting. See Backup & Restore.
A saved login can be locked, each with its own password. On a MySQL connection it is Lock with password in the row's ⋮ menu; on an SFTP-FTP server it is Add Password in its form; on an SSH connection, Add Password in its Connection Options. Each lock has a password of its own, so knowing one opens nothing else. Remove lock (or Remove Password) takes it off.
A lock stops the screens that show the login, not the login. It is for the phone being picked up or handed to somebody.
- A MySQL connection: opening it asks once each time the app is started. Edit Connection, Users, re-pairing, Duplicate and Delete ask every time. Once opened, reading, writing and exporting the database work as usual.
- An SFTP-FTP server: its form, Files on a server and the folder picker on it. An export or an upload to it asks for its password as soon as the server is chosen — Copy to MySQL server too. A MySQL connection paired with a locked server is not locked by it: the two locks are separate.
- An SSH connection: the form, the session itself, and Delete. Stricter on purpose — a shell on your server is the thing itself, not a form about it.
- Delete asks on all of them, and for a local database it asks for that database's own password. Renaming a local database stays open: it leaves the file where it is.
What the lock is not. It is not encryption, and it is not a lock against somebody with your phone and a computer: the app has to be able to read a login to use it, so anyone who takes the app apart can too. Do not lock a connection and give the phone, or a backup of it, to somebody who must not have the login.
Giving someone a connection. Use Users on the connection (section 6) and give them a connection file, never your phone or your backup. Where your server lets the app make them a MySQL login of their own, the server itself limits what they can do, and they may see and edit that connection freely. Where it cannot (shared hosting), the file holds your login: their phone shows Rename instead of Edit Connection, and their backups carry it only sealed with a Backup password, but whoever knows the file's password can still read your login out of it. Make that file only for someone you would trust with your login.
Locks in a backup. The locks go into a backup, so a restore does not quietly take them off. A lock already on this phone is never replaced by the backup's; the backup's are added only where there is none. Without a Backup password the logins themselves are in the backup in the clear (section 8), so the file is only as safe as wherever you keep it.
Your database passwords are the exception. They are never written into a backup in any form. After a restore or a reinstall an encrypted database still asks for its password, and nothing in the app can recover it for you. Keep it somewhere you trust.
A backup keeps the lock on. A password-protected database goes into a backup as the encrypted file it is, so the backup is safe to leave somewhere else and needs the same password wherever it lands.
Everything is yours. The databases sit on your phone, exports go where you send them, and the only servers the app talks to are the ones you configure yourself.

Keep your own backups of anything important. My Database Pro → Back up everything takes the lot in one file; a ZIP export of one database before a risky change takes seconds and includes its images.

18. Tips & Good Habits

New to SQL? Open the Web View and pick the pre-installed SQLite Tutorial page, then try what you learn straight away in SQL Query — the tool row makes that two taps each way.
Drag the tool row to whichever end of the screen your thumb prefers. It stays there.
Use the reminder note in the Code Editor as a running journal: it autosaves as you type, so nothing is lost even if the app closes.
Before making risky changes to an important database, export a ZIP backup first — it takes seconds and includes your images.
If you are unsure what a column or table is called, let the AI assistant write the query — it always uses the exact real names from your database.
Add the SFTP servers in the Servers tool first, then pick one on the database (or on the MySQL connection). Every export after that is a couple of taps, and a folder upload only sends what actually changed.
For a public MySQL server that also serves the image API, use a hostname rather than an IP and leave Use SSL on — the certificate is issued for a name. If MySQL and PHP are on different hosts, put the website in Image API host and leave Server host as the database hostname.