|
Datenbank: MySQL • Version: 5.5 • Zugriff über: MySQL Workbench
MySQL Workbench
Hi zuammen
Vor einiger Zeit habe ich mir MySQL Workbench installiert und damit meine DB modelliert. In letzter Zeit war ich auch etwas am damit herumspielen, mit meinen schlechten Englischkenntnissen die Hilfedateien von Workbench zu studieren (und teilweise mit Google zu übersetzen). Tja, und nun hab ichs doch tatsächlich geschafft: MySQL Workbench zeigt mir eine Fehlermeldung, wenn ich mein Modell per ForwardEngeering in eine DB umsetzen lassen will. Meistens wars dann so, dass meine Tabellen in der DB erstellt wurden, ausser der einen, die mir Workbench als fehlerhaft meldete und allenfalls zwei damit verbundenen Interselektionstabellen - die können ja nicht erstellt werden, wenn eine von zwei Tabellen einer n:mBeziehung nicht erstellt wird. Neuerdings erstellt Workbench aber gar keine Tabellen mehr. Die Meldung: Zitat:
Zitat:
Im DB-Verzeichnis findet sich anschliessend gerade mal die Optionsdatei. Ich bin inzwischen soweit, dass ich nur noch die Neuinstallation des MySQL Workbench sehe. Das aber könnte nicht so einfach sein, wie es sich anhört, da nicht nur der Server, sondern auch Workbench etliche Dateien in verschiedenen Verzeichnissen speichert. Kennt jemand diese Verzeichnissen? Gruss Delbor |
AW: MySQL Workbench
Zitat:
MySQL wird sich schon was dabei denken, wenn es meldet, dass die Tabelle bereits existiert. Was sagt denn SHOW TABLES dazu? Zeigt es die Tabelle auch an? Ich glaube eigentlich nicht, dass die Neuinstallation der MySQL Workbench hier einen Fehler behebt, zumindest sofern ich dein Prolem richtig verstanden habe. Eher hast du ein Problem mit deinem Server. Liebe Grüße, Valentin |
AW: MySQL Workbench
Hi Valentin
Danke für die schnelle Antwort. Zitat:
Zitat:
Ach ja: weisst du vielleicht gerade, was das bedeutet, wenn im Catalog tree von Workbench die Tabellenbezeichner am Schluss mit einem Punkt gekennzeichnet sind? Gruss Delbor |
AW: MySQL Workbench
Grundsätzlich zu InnoDB unter MySQL: Uns ist nach diversen Rettungsversuchen von Datenbanken ähnliches wiederfahren - heisst die DB an sich war laut MySQl Administrator nicht mehr da, aber beim CREATE TABLE hieß es sie sei es doch. MySQL speichert das Verzeichnis von InnoDBs an anderer Stelle als die Daten, und der Verzeichniseintrag reicht aus, um einen Tabellennamen zu blockieren. Wo die jeweiligen Dateien genau sitzen hängt von deinen Einstellungen ab.
Wenn man es also in der Hand hat, ist der Hinweis niemals manuell an den Dateien selbst zu doktorn das einzig richtige. Im Zweifel würde ich hier MySQL komplett deinstallieren, und ganz neu aufsetzen. Setzt natürlich voraus, dass man sonst nichts wichtiges in der DB verliert - aber wenn man sich schon traut einfach mal Dateien zu löschen, kann das ja eigentlich nicht sein ;) |
AW: MySQL Workbench
Hi Medium
Auch dir vielen Dank für deine Antwort. Ich denke schon, dass es erstmal daran lag, dass ich Workbench mit einem 'X-beliebigen Programm' verwechselte und MySQL schlussendlich doch tiefere Einarbeitung abverlangt. Der eigentliche Client wird mein Programm sein, und das setzt eigentlich ausschliesslich auf Delphis VCL auf. Mit der DB hat es eigentlich gerade mal soviel zu tun, dass es sich von da benötigte Daten holen und nach deren Bearbeitung wieder dahin zurückschreiben soll. Die Komplexität der Daten und deren Umfang lassen aber die Verwendung einer DB als sehr ratsam erscheinen. In der DB selbst kann ich ausser einigen sehr wenigen Testdaten (die ein Zeichensatzproblem zutage brachten), nichts verlieren. Das mit der kompletten Neuinstallation hatte ich schonmal. MySQL war als Dienst installiert und startete irgendwann nicht mehr, und ich wusste nicht, warum. Eine Neuinstallation war erst erfolgreich, nachdem ich unter Win7 das Verzeichnis ProgrammData (nicht Programme) gelöscht hatte. Aus Workbench heraus lässt sich MySQL ja beenden und wieder hochfahren. Wahrscheinlich habe ich da einen Eintrag in einer Systemtabelle ausgelöst, den aber nicht mehr gelöscht (bzw. den Server wieder hochgefahren). So hat Windows offensichtlich den Server gestartet(wie es die 'Dienstanweisung' vorsieht), und Workbench (bzw. der Eintrag in der Systemtabelle) hat ihn wieder heruntergefahren...:lol: Gruss Delbor |
AW: MySQL Workbench
Hast du es denn mal mit DROP TABLE versucht?
Und was passiert eigentlich, wenn man versucht eine Tabelle zu erstellen, wo schon eine gleichnamige Tabelle mit anderen Feldern/Spalten existiert? |
AW: MySQL Workbench
Hi himitsu
Ja. Erstmal hab ich allerdings versucht, die Tabellen anzuzeigen. Die Abfrage lieferte 0 Rows zurück. Etwas erfolgreicher war danach Drop Database - das Resultat war zwar auch 0, aber nac der Abfrage... Show Database lieferte den Fehler 'unbekannt...' zurück. Und als ich jetzt versuchte, mein DB-Modell erstellen zu lassen, hatte ich wieder die Ausgangssituation - die nicht erstellte Tabelle ist wiederum die Bilddatentabelle und die Interselektionstabellen zweier n:m-Beziehungen. Der Code selbst war ja von Workbench erstellt worden - bzw. vom Server selbst. Die entsprechende Syntax selbst kann ja kaum fehlerhaft sein. Den gibt es ja seit Jahren, und daher dürfte er wohl milliardenfach erprobt sein. Allerdings hatte ich den 5 von mir erstellten Tabellen jeweils alle vorgesehenen Felder zugewiesen, bevor ich die Beziehungen einzeichnete. die von Workbench eingefügten Fremd- und Sekundärschlüssel wurden auf diese Weise der Felderliste angehängt. Die fragliche BilddatenTabelle besteht aus 3 Feldern - dem zusammengesetzten Primärschlüssel (AutoincFeld(int), Typfeld(VARCHAR(3) und dem Feld Bilddaten(LONGBLOB). Der Hintergrund ist, dass es von jedem Bild bis zu drei Formate geben kann: das originale RAW-Format (das Original, enthält auch EXIF-Daten), ein Thumbnail(evtl. PNG o. jpeg) und eine Bitmap zur grafischen Bearbeitung(Weissabgleich etc, Umwandlung in Webtaugliches Jpeg). Inzwischen vermute ich den Fehler an zwei möglichen Stellen:
Etwas irritiert hat mich lange Zeit, dass die eine Interselektionstabelle 5 Schlüsselfelder enthält. Da ich aber trotz intensiven Suchens (Google, diverse Foren,MySQL.de) und einer  Konzeptdiskussion keinen Hinweis auf eine negative Auswirkung auf die Performance durch mehrfach zusammengesetzte Schlüssel finden konnte, hab ich diesen Punkt fürs erste als erledigt abgehakt.Gruss Delbor PS: Zitat:
|
AW: MySQL Workbench
Hi zusammen
Kürzlich bin ich in meinem neuen 'schlauen Buch' über einen kurzen, eher unscheinbaren Eintrag gestolpert. Danach sind zusammengesetzte Primärschlüssel, die ausser int auch andere Datentypen aufweisen, unter InnoDB nicht möglich. So habe ich denn das Typfeld in der Bilddatentabelle(VARCHAR), die ja Teil des Primärschlüssels war, durch 3 Blobfelder für die verschiedenen Formate ersetzt. Und siehe da - alle Tabellen wurden anstandslos erstellt.... Ein weiterer Punkt, den ich hier erwähnen möchte, betrifft die Speicherengine. MySQL verdankt seinen Ruf, schnell zu sein, der Engine MyIsam, verwendet aber standardmässsig heute die vielseitigere InnoDB... Gruss Delbor |
AW: MySQL Workbench
Zitat:
Es ist allerdings fragwürdig, dieses in Zusammenhang mit einem AUTOINC (INT) Feld. Denn dieses Feld ist ja durch den automatisch vergebenen Wert eindeutig. Durch das weitere Feld wird es nicht eindeutiger. Also ist das nur überflüssiger Ballast für den PRIMARY KEY. |
AW: MySQL Workbench
Hi Sir Rufo
Danke für deine Antwort! Es ist möglich, dass die entsprechende Passage in dem Buch für den PrimaryKey den AutoInc voraussetzte und ich diese Tatsache einfach überlesen habe. Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe - mit meinem Programm eingefügte Strings kommen nach wie vor als 'verunstaltete' Zeichhenfolgen daher. Mit einer früheren Version von MySQL(aber auch 5.x) hatte ich die SQL-Stringvariable jeweils als Widestring definiert (D7). Das ist offenbar unter der aktuelllen Version nicht mehr gültig. Gruss Delbor |
AW: MySQL Workbench
Zitat:
|
AW: MySQL Workbench
Zitat:
Zitat:
|
AW: MySQL Workbench
Hi zusammen
Zitat:
Der Zugriffskomponente? Da gibt's bei mir gerade mal die TSQL-Connection, TSQLDataset und TDatasource als Verbindung zu einem DB-Grid. In einem Beispiel zu DBExpress emppfiehlt Embarcadero zwar eine 'Schlange' aus den Komponenten TSQLConnection,TSQLDataset, (TDatasource*), TClientDataSet und TDataSetProvider, die ich aber nicht verwende - ich habs mal versucht, aber irgendwie nicht die richtige Reihenfolge beim setzen der Propertys/nicht die richtige Komponente zum setzen eines/der Propertys erwwischt. Seither begnüge ich mich mit den zuerst genannten 3 Komponenten. Und die bieten keine speziellen Propertys zum setzen des Zeichensatzes an, soweit ich gesehen habe. Nach diesen Erklärungen ist dies aber auch gar nicht nötig - es ist letzlich so oder so eine Frage der Variablendeklaration..Widerspruch wird gerne entgegengenommen. Zitat:
Den Zeichensatz der Connection (nicht Delphis TConnection-Komponente) sollte auch latin1 sein, aber das müsste ich nochmal überprüfen. (*) Die wird m.W. da auch nur benötigt, wenn die SQL-Abfrage kein eigenes Grid zur Datenausgabe erzeugt. Gruss Delbor |
AW: MySQL Workbench
Zitat:
Wenn die verwendete Komponente z.B. nur die DB-Einstellung prüft und Latin1 sieht und dann auf einer utf8-Verbindung uncodiert Sonderzeichen abschickt wird der Server diese Zeichen natürlich als Falsch codiert ansehen und entsprechend Markieren. |
AW: MySQL Workbench
Liste der Anhänge anzeigen (Anzahl: 1)
Hi Bernhard
Hier mal ein Jpeg mit den Einstellungen der entsprechenden Systemvariablen. Da ist alles utf8. Im Konfigurationsfenster des Servers lässt sich allerdings die Collation einstellen. Ich habe das mal auf latin1-swedish_ci geändert. Da bislang keine Änderung erfolgt ist, nehme ich an, dass ein Neustart des Servers erforderlich ist. Wenn ich die verlinkte Hilfeseite alledings richtig interpretiert habe, sollte der normale (Unicode-)String von DelphiXE mit utf8 klarkommen, bzw. umgekehrt... Gruss Delbor |
AW: MySQL Workbench
Zitat:
Zitat:
|
AW: MySQL Workbench
Hi Bernhard
Zitat:
Gruss Delbor |
AW: MySQL Workbench
Hi Bernhard
Zitat:
Datebank-Server innerhalb Japans zB sind wohl kaum mit 1-Byte-Zeichensätzen konfiguriert. Und ausser TCP/IP ist TCP/IP über SSH oder als 3. Möglichkeit über local Socket/Pipe möglich - und eigentlich sollte MySQL nur gerade über letztere Verbindung Zeichensätze mit mehr als einem Byte verarbeiten können - und würde dadurch wohhl für die Verwendung über Internet ausfallen... Also muss ich wohl irgendwas völlig falsch verstanden haben... Gruss Delbor |
AW: MySQL Workbench
Hi zusammen
Dachte ich mir's doch: Das soll Missverständnisse verhindern, die dadurch entstehen könnten: Zitat:
Im Programm lassen sich die Zeichensätze für die aktuelle Session ändern - meine komischen Ausgaben wie zB "Ã#ste" statt Äste sind dann für die Laufzeit des Programms kein Problem mehr. (Wobei das Sharp für ein mir unbekanntes, leicht ähnliches Zeichen steht). Die Syntax: 'SET NAMES ´latin1`. Damit ist der Zeichensatz allerdings nur gerade zur aktuellen Programmlaufzeit gültig - der Zeichensatz des Servers ist weiterhin utf8 (Standard ab 5.?). Zur Beruhigung all jener, für die das Thema auch etwas rätselhaft ist...Gruss Delbor |
AW: MySQL Workbench
Also zunächst mal muss man ja zwischen Character-Set und Collation unterscheiden. Sind ja unterschiedliche Sachen. Die sollten allerdings zusammenpassen. Eine Tabelle mit Character-Set UTF8 und Collation latin1_* macht keinen Sinn. Zweite Aussage: Daten die falsch gespeichert wurden, bleiben auch nach dem Umstellen falsch.
- Character-Set der Tabelle prüfen - Collation der Tabelle prüfen - Beim Aufbauen der Verbindung Sets via SET NAMES und SET CHARACTER SET für die Verbindung einstellen Wird alles explizit gesetzt, ist die Einstellung des Servers übrigens egal. Manche Komponenten haben eine Property für den Character-Set der Verbindung und führen die SET Befehle beim Verbindungsaufbau dann automatisch aus. Normalerweise sollte die Komponente die u.U. nötige Umwandlung von Unicode nach Latin1 und/oder zurück selber hinkriegen. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz