Solution – mysqldump – No database selected when selecting the database

International shortform:

Hi, if you reached this page, because it’s one of five webpages regarding this specific error message, please scroll down to the end.

Und für alle anderen, die lange Form:

Die Shell kann komisch sein, aber die Abwesenheit der Bashshell ist noch zu viel komischeren Sachen fähig, eine davon ist der Bug von Mysqldump keine Datenbank angegeben zu haben.

Hintergrund: Wenn man in Java mit Exec() einen Befehl startet, hat man keine Shell vor sich und damit auch eine Menge Sicherheitsprobleme nicht mehr. Nachteil : u.a. „*“ wird nicht mehr funktionieren, denn das wird von der Bash geparst. Keine Bash => Kein „*“ Keine „<>“ .

Das kennt man noch. Was jetzt kommt, ist allerdings extrem schwer zu debuggen, deswegen bin ich auch ein klein bisschen stolz als einziger im Netz eine Lösung präsentieren zu können, auch wenn die eher trivialer Natur ist. Sucht mal nach der Fehlermeldung, es gibt nur 4 Seiten, die diese Meldung behandeln 😉 (OK, jetzt 5 )

Das hier ist der Befehl:

/usr/bin/mysqldump  --add-locks -e --force -R --triggers --add-drop-table --hex-blob -h localhost --password=dbpass --user=dbuser dbname;

Das erzeugt die Fehlermeldung :

mysqldump: Got error: 1046: No database selected when selecting the database

obwohl eine Datenbank angegeben ist. Gibt man den  Befehl in die Shell ein, geht es sofort ohne Anpassungen. Kleine Anmerkung, auf die Fehlermeldung an sich muß man geistig erstmal kommen, richtig wäre nämlich „no databasename given“

Wie löst man das jetzt, wenn man doch schon alles richtig angegeben hat ?

Na man drückt dem Befehl die Pistole auf die Brust, so daß er sich nicht mehr herausreden kann ;D

/usr/bin/mysqldump  --add-locks -e --force -R --triggers --add-drop-table --hex-blob -h localhost --password=dbpass --user=dbuser --databases dbname

Der kleine Zusatz „–databases“ ist eigentlich dazu da, mehr als eine Datenbank in einen SQL-Dump zu integrieren. Es geht aber auch nur mit einer einzigen Datenbank und komischerweise kommt der Parser jetzt nicht mehr durch einander und erkennt die Datenbank am Ende des Befehls. Es gibt so bescheuerte Bugs 😀

Ok, Hello there.  You found this page, because it’s the only one marked as solution to the problem, that you give mysqldump a databasename and it says, that you did not. It’s a bug that occurs only in the absence of bash. You counter it by adding „–databases “ infront of your databasename. See the above example if your uncertain how to do it.

If you wanne see more articles in english, please leave a comment about it. Cu.

 

2038 ist schneller da als man denkt

In 23 Jahren, wenn die Unixwelt Y2K erlebt, wird die Welt zusammenbrechen.

Wir haben ja jetzt 2015 und die gängigste Datenbank MySQL legt Timestampfelder immer noch als 32-Bit Feld an. Es sollte ja eigentlich kein Problem sein dort intern 64-Bit zu benutzen, aber wie das so ist, die Tücke liegt im Detail.

MySQL speichert die Daten in einer großen Datei im Binärformat. In dem Augenblick wo dieser Feldtype auf 64-Bit umgestellt wird, muß zwangsweise mysql_upgrade laufen, sonst gibt es nur Probleme. Und wie das Leben so spielt,  mysql_upgrade wird bei normalen Updates eigentlich nie ausgeführt. Da muß man als Admin selbst machen.

„Wenn das noch 23 Jahre sind, warum nervst Du jetzt schon rum?“

Ich kenne Euch halt 🙂 Dabei wollte ich auf etwas anderes hinaus:

Führt öfter mal mysql_upgrade durch. Erst dieser Befehl schreibt die Strukturen im Mysql um z.b. wenn neue Felder in der „mysql“ Datenbank hinzugekommen sind. Mit den Updates von Fedora 20 auf 21 z.b. mußte so ein mysql_upgrade auch zwangsweise laufen, wenn man die neuen „Features“ benutzen wollte.

Zurück zum Jahr 2038. Es werden dann mehr als 40 Jahre zwischen den Leuten liegen, die Y2K mitgeplant haben und denen, die dann für die Systeme verantwortlich sind. Da darf man annehmen, daß die meisten das auf die gleiche leichte Schulter nehmen werden, wie Ihre Vorfahren.

Deswegen wünsche ich heute schon einen schönen Weltuntergang 😉

Tip: Update der Inhalte eines SQL Views

In einer Datenbank wie MySQL kann man sich Selects als Pseudotabellen anlegen und dann selbst wieder über den diese Tabelle einen Select bauen. So etwas nennt man einen View.

Beispiel:

SELECT a.vorname,a.name,b.beruf as beruf FROM Personen as a,Berufe as b WHERE a.berufsid=b.id;

Wenn man diesen Select als View anlegt, hat man drei Felder : Vorname,Name,Beruf

Nennen wir den View mal Test, wäre dieser Select möglich :

SELECT vorname,name FROM Test WHERE beruf = „Bäcker“;

Wenn man nun versucht den VIEW mit UPDATE zu ändern, geht das eigentlich nicht, weil es eine nicht eindeutige Beziehung der Datensätze untereinander ist.

Für mein aktuelles Pandora Projekt habe ich nun einen View gebaut, bei dem das Update tatsächlich möglich ist:

select `pa`.`id` AS `id`,`pa`.`vorname` AS `vorname`,`pa`.`nachname` AS `nachname`,`pa`.`server` AS `server`,`pc`.`value` AS `friendmode` from (`pandora`.`pandora_config` `pc` join `pandora`.`pandora_account` `pa`) where ((`pa`.`id` = `pc`.`uid`) and (`pc`.`name` = ‚michsuchen‘))

Das funktioniert aufgrund dieser Beziehung „((`pa`.`id` = `pc`.`uid`)“ , denn in beiden Tabellen gibt es exakt einen eindeutigen Datensatz. d.b. :

Für jede Person gibt es exakt einen Config Eintrag in der anderen Tabelle. Damit kann der Datenbankserver jetzt die logische Verbindung der Datensätze „rückwärts“ auflösen und in der richtigen Tabelle den richtigen Eintrag ändern:

UPDATE `pandora_userliste` SET friendmode = ‚erlauben‘ WHERE vorname =’meinvorname‘;

Damit ist der View Read/Writeable geworden was es man mit Hilfe des ORDB Frameworks ausnutzen kann, denn Views werden ein Java Datenobjekte erzeugt. Über Views lassen sich schlanke Strukturen und Datenbankobjekte erzeugen, die dazu noch updatefähig sein können (aber nicht müssen). Als Folge davon erhält man übersichtliche Datenbankstrukturen, die von einem Menschen leicht gelesen und verstanden werden können, aber trotzdem Datenbanktechnisch höchst performant gestaltet sein können.

Error 2006: Server has gone away

Diese falsche Fehlermeldung eines MySQL Servers, verleitet einen unweigerlich dazu an einen echten Fehler des Servers zu denken. Glücklicherweise kann es auch andere Fehlergründe geben. Einen davon, zeigen wir Ihnen heute:

Wenn Sie einen SQL DUMP importieren, der 2,4 MB groß ist, aber sqlmäßig nur aus einer Zeile des Schemas:

insert into datentabelle ( spalte1,spalte2,spalte3) values (1,2,3),(2,3,4) ,(3,4,5) ,(4,5,6) ,(2384,4233,5674),..... 2 MB später ... ;

besteht, müssen Sie sich nicht wundern, wenn es nicht geht. Die Zeile ist schlicht intern zu lang.

Abhilfe schafft der MySQL eigene Befehl replace :

 replace ")," ");insert into datentabelle  ( spalte1, spalte2, spalte3 ) values " --  /tmp/output-1.sql

Wenn Sie diesen neuen SQL Dump einspielen, wird dies anstandslos verarbeitet werden.