DB3 ↔ MySQL

Carried out: 24. July 2026
Source database: dbx/modules/dbxContact/db/dbxContact.db3
MySQL target: dbxRoundtrip / Database dbx roundtrip

Result

The SQLite database of the module dbxContact was secured, transferred via the dbxAdmin transfer to MySQL, there via the real dbxContact admin-Processes are read and tested in writing and then transferred back to a newly generated DB3. The two DDs finally show again:

The returned DB3 is integer, structurally the same and technically the same as the original. The only raw value deviations are empty time values: An original empty string was corrected in MySQL as SQL NULL and therefore came as NULL back. This prevents zero-date values and errors under strict MySQL-SQL modes.

Binding architecture

All technical data access remained within the dbxapp layers:

• connection, queries and transactions about dbxDB
• Scheme, backup, restore and transfer via dbxDD
• Admin interface and transfer dialog via the existing dbxAdmin templates and forms
• technical usage test on the existing dbxContact admin-Module with dbxReport, dbxForm and dbxTPL

There was no direct PDO query outside of dbxDB A parallel transfer path is built. The GET calls and module parameters remained unchanged. An additional dbx token was not required: The existing admin and module access already checks its permissions itself.

Secured starting position

The unchanged starting point is below:

SHA-256 of the original:

The completed returned file was additionally transferred as dbxContact.final.db3 archived. Your hash is identical to the currently used module DB3:

Another file hash is normal for a newly built SQLite file: page size, free pages, B-tree arrangement and VACUUM are not technical data. Therefore, an additional structural and data-related comparison was carried out.

Expiry date

1. Original DB3 and both DD files were backed up before the first change.
2. The MySQL service, PDO drivers and connection were tested.
3. For the isolated test, the server was dbxRoundtrip used. The production standard entry dbxapp remains disabled because its effectively loaded local access configuration does not authenticate. Thus, a known misconfiguration does not generate runtime errors.
4. Over ?dbx module=dbxAdmin&dbx run1=db&dbx run2=list db&dbx page=admin were: contact request and contact message transferred to MySQL.
5. contactRequest.dd.php and contactMessage.dd.php showed during the usage test dbxRoundtrip.
6. The real contact report read 4 requests from MySQL. In addition, a transactional DD test resulted in INSTALLATE, SELECTIVE, UPDATE, DELETE, ROLLBACK; After that, exactly 4 records were still available.
7. A new empty dbxContact.db3 was created and both tables were transferred back via the same dbxAdmin transfer.
8. Both DDs were on dbxContact|dbxContact.db3 deferred.
9. Report, DD-CRUD, integrity and logical comparison were again executed against the new SQLite file.
10. The admin test bypass used exclusively locally has been removed. After logout, the admin link shows only the login again.

Comparative result

Both files provide PRAGMA integrity check the value OK. The semantic data hashes are:

Gross value deviations exist exclusively in '' to NULL:

• contact request.closed date: 3 Values
• contact request.confirm mail sent date: 1 value
• contact request.mail sent date: 3 Values
• contact request.user hidden date: 2 Values
• contact message.mail sent date: 5 Values

All existing date values including milliseconds are obtained. For example, the browser shows again 07.06.2026 10:46:48.854 and not an artificially filled representation with six decimal places.

Central corrections needed

The corrections are deliberately in the common places, so that all modules use the same simple and secure process:

• dbxDB::connect_db_server() recognizes an already open dynamic module SQLite connection. Previously, the second access to the same dynamic server failed despite the valid PDO connection.
• The original DB error message remains after writing a system message; A successful internal insert no longer overwrites them.
• dbxDD generates MySQL temporary types with six-digit accuracy so that existing fractions are not cut off.
• DD backups additionally store the source field types. Old backups without this metadata remain readable.
• The restore converts empty MySQL time values into NULL and normalizes in the SQLite return path only technically attached zeros of the fractions of a second. Content values remain unchanged.

Reproducible tests

tools/db-roundtrip-compare.php Used exclusively dbxDB and dbxDD. It checks integrity, tables, columns, field definitions, indices, raw values and semantically normalized useful data.

Final status of the automated test run:

The file dbx/modules/dbx/tpl/php/dd_file.php is a generator template with not yet replaced {...}Markers and therefore deliberately not an independently inkable PHP runtime file.

Restoration

If a problem is detected later, the current module DB3 can be backed up by dbxContact.original.db3 Replacement from the archive. Subsequently, the two archived DD files are replayed and PRAGMA integrity check As well as checking the contact report. The dbx roundtrip- Schema is maintained as an isolated, functioning MySQL test target; no production DD finally refers to this.