# aktuellen Stand der Maschinen ermitteln...
mratix@crocache:~$ mysql --version
mysql  Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

mratix@cronas:~$ mysql --version
mysql  Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

mratix@crohpdesk:~$ mysql --version
mysql  Ver 15.1 Distrib 10.0.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

mratix@crodevo:~$ mysql --version
mysql  Ver 14.14 Distrib 5.7.30, for Linux (x86_64) using  EditLine wrapper

# Demnach sind alle für den mysql-json-support ungeeignet.

# Auch der letzte Server 5.7 (mein developer), welcher bereits im vorherigen Anlauf aktualisiert wurde, ist trotzdem nicht geeignet.
# Übrigens, es sind alles finale Versionen aus dem offiziellen LTS Baum. Bitte ggf. überdenken, ob eine derartig hohe Anforderung wirklich begründet und nötg ist.
# Ich für meinen Teil, bin nicht bereit deswegen* den Datenbankserver (Cluster/Mirror) auf eine höhere Minor zu aktualisieren. Darauf laufen etwa 15 Applikationen mit über 25 aktive Datenbanken. Keine beschwert sich über eine Inkompabilität oder fehlendes Feature.

# Nach etlicher Recherche nach einem Strohhalm, eine Möglichkeit, welche ich hier durcharbeite und als Log darstelle.

# https://mariadb.com/kb/en/json-data-type/
# JSON Data Type
# MariaDB starting with 10.2.7
# The JSON alias was added in MariaDB 10.2.7. This was done to make it possible to use JSON columns in statement based
# replication from MySQL to MariaDB and to make it possible for MariaDB to read mysqldumps from MySQL.

# Hinweis: spätestens jetzt sollte Man(n) einen Dump/Backup der Datenbanken machen. Der Upgrade eines Datenbankservers ist immer kritisch!

# Los geht's, Repository einbinden
# https://downloads.mariadb.org/mariadb/repositories/
sudo apt-get install software-properties-common
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
# für ubuntu xenial
sudo add-apt-repository 'deb [arch=amd64] http://mirror.mva-n.net/mariadb/repo/10.4/ubuntu xenial main'
# oder für debian stretch
sudo add-apt-repository 'deb [arch=amd64] http://mirror.mva-n.net/mariadb/repo/10.4/debian stretch main'

sudo apt-get update
# Vorsicht: an dieser Stelle bloß kein 'apt-get upgrade' absetzen! Der schlägt tatsächlich fehl und hinterlässt etwas (=etwas mehr bis viel) Chaos. Statt dessen funktioniert
sudo apt-get install mariadb-server
sudo dpkg-reconfigure mariadb-server
sudo systemctl restart mariadb.service
sudo dpkg-reconfigure phpmyadmin # Konfiguration neu schreiben und einklinken (bei mir war sie anschließend hinüber)
sudo systemctl restart apache2.service
# reminder: check old mysql fragments

mratix@crohpdesk:~$ mysql --version 
mysql  Ver 15.1 Distrib 10.4.12-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
# Super, die Voraussetzung ist nun geschaffen.

# In der EleLa Konfiguration von sqlite3 -> MariaDB umstellen
# und eine neue Datenstruktur mit dem Knöpchen erstellen lassen.
# 00:04:19 Database and tables successfully created 192.168.178.55.elela

# EleLa.ini wurde nach der Umstellung durcheinander gewürfelt und ist beschädigt (wie es Jaroslaw zuvor feststellte).
# Hier ein Auszug für das spätere Debuggen:
mratix@crodevo:~/EleLa$ diff EleLa.ini EleLa.ini.sq3 
1,2c1,7
< efon]
< Port= 
---
> [Projekt]
> DefHandbuchDir=./storage/projects
> GeraetDefHandbuchDir=./storage/devices
> DokuDefHandbuchDir=./storage/doku
> 
> [Telefon]
> Port=
4c9
< DialPrefix= 
---
> DialPrefix=
6,7c11,12
< EXE= 
< EXEParam= 
---
> EXE=
> EXEParam=
17c22
< LanguageFile= 
---
> LanguageFile=
25,26c30,31
< StartCopy= 
< StartRun= 
---
> StartCopy=
> StartRun=
36,37c41,42
< Protocol=MariaDB-10
< HostName=192.168.178.55
---
> Protocol=sqlite
> HostName=10.16.1.85
39c44
< Database=elela
---
> Database=/home/mratix/EleLa/EleLa.sq3
46,51c51
< DefLibDir= 
< 
< [Projekt]
< DefHandbuchDir=/home/mratix/EleLa/Projekt
< GeraetDefHandbuchDir=/home/mratix/EleLa/Gerät
< DokuDefHandbuchDir=/home/mratix/EleLa/Doku
---
> DefLibDir=

# die ini händisch bearbeiten, eine Kopie der vorherigen nehmen und den Abschnitt [DB] entsprechend anpassen.
# Anmerkung: der obere Abschnitt [Projekt] stammt aus meiner Konfiguration. Der untere wurde automatisch zusammengebaut und angehängt.

# Backup der leeren Datenbank machen
mratix@crohpdesk:~/backup$ mysqldump -p -u elela elela > elela31_dump_clean.sql

# der erste Start mit MySQL:
01:08:32 Connect database...
01:08:32 DB.Version: SQLite-DLL: 3.11.0 / MySQL: 10.4.12-MariaDB-1:10.4.12+maria~xenial
01:08:32 Database Version: V3.1.18B30
01:08:33 Error: Cannot open database! SQL Error: Unknown column 'TecData' in 'field list' (TypTreeOpen)
01:08:33 Connect database...
01:08:33 DB.Version: SQLite-DLL: 3.11.0 / MySQL: 10.4.12-MariaDB-1:10.4.12+maria~xenial
01:08:33 Database Version: V3.1.18B30
01:08:33 Database connected.
01:09:43 E: SQL Error: Unknown column 'TecData' in 'field list' (tmrBackgroundTimer|TypTreeOpen|dsTypDataChange_1|pgMainChange37|dsPPosDataChange|TfrmTecDataShowInline.SetTecDataI0)/(  $00000000008DE78C)

# Ein Fehler scheint noch zu bestehen - obwohl vorhin ein sauberer Durchlauf gemeldet wurde. Wie auch immer, behautet wird dass er jetzt connected ist, auch wenn eine Spalte nicht passt.

# Der Versuch die sq3 Daten nun zu importieren schlägt als Folgefehler und anschließend taucht ein weiterer Fehler (import:translate) auf. Also ins Leere.

Zurück zum Anfang, zurück zu sqlite...