MySQL und OpenGeoDB

  • Servus VA-ler

    Fehlersuche und Websuche brachten mich bisher leider nicht weiter.

    Ich versuche gerade die Datenbanken für opengeodb zu füllen, allerdings klappt der Import von keiner der gezogenen .sql bzw. .gz Dateien.

    Ich vermute, das liegt an der fehlerhaften Struktur der .sql scripte, denn zum insert gehört nach meinem Verständnis nicht nur der Tabellenname und die Werte, sondern auch WOHIN diese Werte inserted werden sollen, also die rows.

    Codeschnipsel:

    SQL
    INSERT INTO geodb_locations VALUES (0,1);
    INSERT INTO geodb_hierarchies VALUES(100,1,100,null,null,null,null,null,null,null,null,null,null,'3000-01-01',300500000);
    INSERT INTO geodb_locations VALUES(100,100100000);
    INSERT INTO geodb_textdata VALUES(100,'afrika',500100002,'de',0,0,null,null,'3000-01-01',300500000);
    INSERT INTO geodb_textdata VALUES(100,'africa',500100002,'en',0,1,null,null,'3000-01-01',300500000);
    INSERT INTO geodb_textdata VALUES(100,'Africa',500100000,'en',0,1,null,null,'3000-01-01',300500000);
    INSERT INTO geodb_textdata VALUES(100,'Afrika',500100000,'de',0,0,null,null,'3000-01-01',300500000);
    INSERT INTO geodb_hierarchies VALUES(101,1,101,null,null,null,null,null,null,null,null,null,null,'3000-01-01',300500000);

    Fehlermeldung des sql-servers:

    Zitat von phpMyAdmin

    Fehler

    SQL-Befehl:

    INSERT INTO geodb_locations
    VALUES ( 100, 100100000 ) ;

    MySQL meldet:
    #1030 - Got error -1 from storage engine


    Wie geil :rolleyes: - "error nummer -1" - bedeuted also unbekannter Fehler, oder was?
    Habe den Import nach den Tutorialangaben mit mehreren .sql und .gz dumps versucht, kommen immer wieder die selben Meldungen, auch bei Veränderten Importeinstellungen :S

    LINKS: Tutorial - Quelldateien

    Bin ich zu doof, und sehe nicht, wie ich das korrekt importieren soll, oder sind die anderen zu blöd, die den Kram einfach schrottig gescripted/gedumpt haben?


    Grüße
    - styvi -

  • Du hast schon eine Datenbank eingerichtet und auch in Verwendung genommen?

    Code
    CREATE DATABASE mygeodb;USE mygeodb;

    Und dann die Tabellen passend mit CREATE TABLE erstellt? Bevor du Mal Daten einpflegen kannst, muß schon erst die Struktur (DB + Tables und deren Fields) stehen.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (24. Juni 2014 um 22:31)

  • Hi GAT,

    ja sicher, Struktur, also Tables, sind erstellt, nur kann ich diese nicht mit den Daten füllen. Auch händisch über die sql Befehlseingabe nicht :|

    Das mache ich übrigens gerade in einer zweiten db - zum Test, weil es danach als Unterwerte in meiner Forumsdatenbank laufen soll - daher teste ich den "use" mal eben.

    EDIT:
    Interessante Fehlermeldung 8|

    Zitat von phpMyAdmin

    Fehler

    SQL-Befehl:

    USE geodb_locations;

    MySQL meldet: Dokumentation
    #1044 - Access denied for user 'xxxuserxxx'@'localhost' to database 'geodb_locations'

    Aber damit ^ kann man wenigstens mal was anfangen - nur was?

  • Das is eine Tabelle, keine DB. Du kannst keine Tabelle "usen", nur eine DB...

    Gültige Statements die sich auf Tabellen beziehen wären CREATE, INSERT, UPDATE, DROP z.B., aber nicht USE. Ausnahme wäre, wenn deine DB genau so heißt wie die Tabelle 'geodb_locations'.

    Edit: Wenn deine Struktur wirklich steht, dann mußt du den Import Queries, die man da runterladen kann zumindest ein 'USE <deineDatenbank>;' voranstellen.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (24. Juni 2014 um 23:04)

  • Da ich da schon direkt in der Datenbank stehe, bringt das "use" nichts - weder positiv, noch negativ.
    Bleibt bei:

    Zitat von pMA

    Fehler
    SQL-Befehl:
    INSERT INTO geodb_locations
    VALUES ( 0, 1 ) ;

    MySQL meldet:
    #1030 - Got error -1 from storage engine

    Entweder liegt ein Fehler in phpMyAdmin und der sql Verarbeitung vor, oder in den sourcen ?(
    Manchmal würde ich echt lieber closed-source Software nutzen, da jammert man kurz rum und ein anderer darf sich mit den Probs beschäftigen, weil man ja dafür bezahlt hat :rolleyes:

    Egal, Jammern gilt nicht, ich wills auch hinbekommen und wissen, was da nicht stimmt - und das möglichst unter geringst möglichem Zeiteinsatz.
    Ich komme allerdings mit der Denkweise der Scripter der db-Files nur noch nicht so ganz klar :whistling:

    Blöderweise ist zu dem Thema fast nichts zu finden, nur Zeug von vor ~6 Jahren - oder ich suche einfach falsch :(

  • Der Fehler hängt offenbar mit dem Tabellenformat InnoDB und dem SQLserver zusammen.
    Erstellt man die Tables in MyIsam funktioniert der Import bis zu einem bestimmten Punkt, wo irgendwas doppelt vorhanden sein soll :rolleyes:

    Nach diesen Infos hier muß ich wohl mal meinen Webhoster zum SQL restart animieren - manchmal wäre ein eigener Webserver schon nicht schlecht, aber leider auch teurer.

    Ich lese mir das morgen erstmal in Ruhe durch - ich habe heute echt keinen Nerv mehr dazu :sleeping:
    Mir geht dieser unkonforme db-kram sowieso mächtig auf den Zeiger :adsh:

  • InnoDB sollte eigentlich seit MySQL 5.1 Standard sein, hast da einen älteren Server? Oder wurde die Config umgestellt, so daß weiterhin MyISAM default ist?

    Die CREATE TABLE Statements spezifizieren eigentlich schon TYPE=InnoDB pro Table. Damit sollte jede Tabelle als InnoDB angelegt werden, außer der Support dafür wurde wirklich im SQL Server selbst deaktiviert (warum auch immer man so etwas machen sollte). Vielleicht ist der Server auch so neu, daß er TYPE nicht mehr versteht, das ist eigentlich eine sehr veraltete Option. Statt der TYPE Syntax sollte man heute eher ENGINE=InnoDB verwenden.

    Für den Fall daß du deine Tabellenstruktur mit MyISAM angelegt haben solltest, lösch einfach alles (ist simpler) und lege die Tabellen neu an, mit Option ENGINE=InnoDB hinter jedem CREATE TABLE Statement, wenn du MySQL 5.1 oder neuer hast (ansonsten TYPE=InnoDB wie unten schon gezeigt). Das könnte ca. so aussehen:

    kA wie sehr MySQL noch den SQL Sprachstandards folgt. Nachdem jeder SQL Entwickler seine Sprache selbst als standardkonform absegnen kann (eine externe Organisation zur Prüfung der Konformität existiert nicht mehr) ist es halt wohl ein wenig chaotisch. Wobei ich das nicht beurteilen kann, ich kenne die ISO Standards für SQL nicht wirklich.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (25. Juni 2014 um 08:07)

  • Hallo GAT,

    die scripte hatte ich schon umgetextet und die tables droped und per sql in MyIsam erstellt, dann ging der Import ja, wie ich schrieb. Ich hatte die Idee in MyIsam zu importieren und dann auf InnoDB umzustellen - war offenbar ein Schuß in den Ofen X(
    Auch mit den alten sql scripten (kompatibel bis 3.23 bzw. 4.0) erfolgt keine Besserung.
    Da ich nichts im Zusammenhang zu opengeodb fand, gehe ich stark von einer Servermis(t)config aus.
    Bei den meisten anderen usern scheint es ja zu klappen, oder die verwerfen das gleich kpl. und schreiben nichts dazu.

    Folgende SW Ver. laufen auf dem Server (Auszug aus phpinfo):
    Apache/2.2.16 (Debian) mod_fcgid/2.3.6 mod_ssl/2.2.16 OpenSSL/0.9.8o
    PHP Version 5.3.3-7+squeeze19
    MySQL Client API version 5.1.73
    mysqli Client API library version 5.1.73
    sqlite 2 + 3 (3.7.3)

    An zu alten Versionen sollte es demnach nicht liegen, sind ja wesentlich neuer, als die von opengeodb geforderten.

    Aber ich glaube, um Mecker an den Hoster komme ich nicht drumherum, irgendeine cfg scheint da falsch zu sein - der soll erstmal schauen was los ist, logs auswerten und dann schaun wir mal.

    Meine Hoffnung, daß diese Problematik hier irgendwem anders noch bekannt wäre, und auf eine fixe Lösung, schwindet langsam. Ich muß das auch erstmal hinten anstellen, zu viele andere Dinge sind vorrangig zu erledigen und da pressierts.

    Danke Dir jedenfalls herzlich, das Du Zeit und Gedankenkraft für meine Frage aufgebracht hast.
    Falls Du noch nen Einfall hast, feel free to post :)

    Hier noch der InnoDB Status:


    Bis auf die fehlgeschlagenen Leseanfrage schauts für mich normal ?(
    Bin da auch nicht ganz so firm, da Autodidakt :whistling:

    Grüße
    - styvi -

  • Das passt schon. Meine Idee war eher, MyISAM komplett zu verwerfen. Also als InnoDB CREATEn und dann INSERTen, und MyISAM nie anfassen.

    Mein Homeserver hat (bis aufs Betriebssystem) eine sehr ähnliche Konfiguration was die Versionsnummern angeht. Habs einfach Mal versucht mit dem von mir hier geposteten Code für's Erstellen der Struktur und dann mit LI.sql und BE.sql von deinen Datenquellen. Konnte beim Import dieser zwei Mal keinerlei Probleme feststellen. Ansonsten könnte man auch noch einen Komplett Dump ziehen (aus dem Unterordner "dumps" in deiner Quelle) und den reinzuklopfen versuchen. Ist halt ein 98MB SQL Query, das könnte per phpMyAdmin schon unlustig werden, außer du kannst ihm direkt das gzip-komprimierte Teil von dort verfüttern, meiner kanns. Dann darf's nur nicht zu lange laufen, also keinen PHP Timeout erzeugen.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    2 Mal editiert, zuletzt von GrandAdmiralThrawn (25. Juni 2014 um 21:06)

  • Sers GAT

    Hatte das mit den .gz auch versucht, wird mir den gleichen Fehlermeldungen abgebrochen.
    Da es bei Dir auch funktioniert, deutet das nun noch stärker auf eine Servermis(t)conf hin.
    Ich kann nicht genau sagen, welche Wege zum Einpflegen nun schon ausprobiert habe, aber es dürften knapp 15 sein.
    Incl. Tables und dann einpflegen, dann auch mit Tables in einem Rutsch erstellen, diverse Arten einzupflegen etc.
    Son Bockmist hatte ich bisher nie mit den db. Laune dazu auch nicht mehr wirklich, da viel zu tun im mom. Gehe da im Laufe nächster Woche nochmal dran.

    Danke für Deine Mithilfe, bin über die Unterstützung echt erfreut.

    Grüße
    - styvi -

  • Ok, bin schon gespannt was der Betreiber sagt...

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"