MySQL-Tabellen aktualisieren

[Christl]

Hallo zusammen...!

ich hab ein grundsätzliches Problem bei MySQL:

nämlich Tabellen zu aktualisieren. Kann sein, dass ich da einem Denkfehler unterliege, vielleicht könnt ihr mir draufhelfen:

Ich exportiere mittels ODBC Daten in eine MySQL-Datenbank/Tabelle. Leider kann ich hier keinen Primary-Key vergeben, da mir sonst das exportierende Programm einen Fehler meldet und den Export einfach abbricht.

Ich dachte mir, nun gut, bau Dir einfach eine zweite Tabelle, die
a) mit einem Primary-Key ausgestattet ist und
b) regelmässig von der ersten "upgedatet" wird. (Das zu automatisieren ist ein weiteres Problem, aber na gut. Vielleicht weiss da ja auch jemand was.. *hoff*)

Ich habs mit INSERT INTO probiert (Option IGNORE), aber dann werden einfach nur neue Datensätze, sofern vorhanden, angefügt, Änderungen bleiben aber unberücksichtigt. Ohne IGNORE bringt er einen Fehler, wegen des Primary Key.
REPLACE funktioniert komischerweise auch nicht.... Warum ist mir schleierhaft... *verzweifel*
Ich habs so geschrieben:

REPLACE tabelle_1 (Feld_1, Feld_2, Feld_3) SELECT Feld_1, Feld_2, Feld_3 FROM tabelle_2 ORDER BY Feld_1

Und UPDATE funktioniert nicht mit 2 Tabellen.....
Ach ja: es ist Version 3.x , also noch nix mit Verschachtelungen etc...

Danke schon mal!

[Philipp Hasenfratz]

Halihallo Christl

Ich exportiere mittels ODBC Daten in eine MySQL-Datenbank/Tabelle. Leider kann ich hier keinen Primary-Key vergeben, da mir sonst das exportierende Programm einen Fehler meldet und den Export einfach abbricht.

Fehlermeldung? - Beispiel eines Queries, der (den|die) Fehler verursacht. Ich vermute,
dass ODBC entweder deine Eingabe nicht versteht (Syntax des Queries), oder dass MySQL
den Query (wiederum Syntax) nicht versteht.

Ich dachte mir, nun gut, bau Dir einfach eine zweite Tabelle, die
a) mit einem Primary-Key ausgestattet ist und
b) regelmässig von der ersten "upgedatet" wird. (Das zu automatisieren ist ein weiteres Problem, aber na gut. Vielleicht weiss da ja auch jemand was.. *hoff*)

Das ist keine Lösung sondern ein Disaster. Wenn man ein Problem hat, sollte man versuchen
dieses zu lösen und nicht weitere zu erstellen. Ich kann verstehen, dass einige sich
versucht fühlen, solche "Lösungen" zu fabrizieren; aber das ist Unfug (man soll das
Datenbankschema nicht ändern, nur weil ein CREATE TABLE nicht funktioniert).

Ich habs mit INSERT INTO probiert (Option IGNORE), aber dann werden einfach nur neue Datensätze, sofern vorhanden, angefügt, Änderungen bleiben aber unberücksichtigt. Ohne IGNORE bringt er einen Fehler, wegen des Primary Key.

Was hat ein INSERT INTO mit Primary Key's zu tun? - Wie synchronisierst du die Daten?
Es ist klar, dass du nix einfügen kannst, was den gleichen Primary Key wie ein anderer
Datensatz hat.

REPLACE funktioniert komischerweise auch nicht.... Warum ist mir schleierhaft... *verzweifel*

Nun, dann zieh den Schleier aus und lies uns die Fehlermeldung vor.
Mit einem Schleier vor dem Haupt lässt sich bekanntlich schlecht Programmieren (es sei
denn der Computer liest dir alles vor)... :-)

REPLACE tabelle_1 (Feld_1, Feld_2, Feld_3) SELECT Feld_1, Feld_2, Feld_3 FROM tabelle_2 ORDER BY Feld_1

Und was soll MySQL damit anfangen? - Das mag ODBC bzw. SQL konform sein, nicht jedoch
für den MySQL-SQL Dialekt.

Und UPDATE funktioniert nicht mit 2 Tabellen.....
Ach ja: es ist Version 3.x , also noch nix mit Verschachtelungen etc...

Was folgerst du aus dieser Aussage?

---
Fazit: Codebeispiel, Queries und Fehlermeldungen posten. Danke.
---

Viele Grüsse

Philipp

[Christl]

Habediere Philipp!

Halihallo Christl
Fehlermeldung? - Beispiel eines Queries, der (den|die) Fehler verursacht. Ich vermute,
dass ODBC entweder deine Eingabe nicht versteht (Syntax des Queries), oder dass MySQL
den Query (wiederum Syntax) nicht versteht.

Hm, das exportierende Büro-/Lagerverwaltungsprogramm (BLVP) bringt einfach nur eine Zugriffsverletzung unter Adresse 0000000000... Kann man nix mit anfangen...
Ich habe den MySQL-ODBC-Treiber unter Win2000 installiert, und öffne im BLVP unter "exportieren" die MySQL-Datenbank als ADO-Datenquelle. Bis dahin läuft alles. Ich kann auch exportieren, d.h. die Datensätze (über 25000) werden einfach hinten angehängt, das BLVP überschreibt die Datei einfach nicht.. (oder updatet auch nicht..)
Da dieser Export auch ein bischen dauert (so 20 - 25 min) kann man in der Zeit ja auch nicht zugreifen...

Das ist keine Lösung sondern ein Disaster. Wenn man ein Problem hat, sollte man versuchen
dieses zu lösen und nicht weitere zu erstellen. Ich kann verstehen, dass einige sich
versucht fühlen, solche "Lösungen" zu fabrizieren; aber das ist Unfug (man soll das
Datenbankschema nicht ändern, nur weil ein CREATE TABLE nicht funktioniert).

Hm, 2.Tabelle wegen siehe oben... Zugriff während des Exports geht nid. Und die DB soll ja mal im Internet stehen...

Nun, dann zieh den Schleier aus und lies uns die Fehlermeldung vor.
Mit einem Schleier vor dem Haupt lässt sich bekanntlich schlecht Programmieren (es sei
denn der Computer liest dir alles vor)... :-)

REPLACE tabelle_1 (Feld_1, Feld_2, Feld_3) SELECT Feld_1, Feld_2, Feld_3 FROM tabelle_2 ORDER BY Feld_1

Und was soll MySQL damit anfangen? - Das mag ODBC bzw. SQL konform sein, nicht jedoch
für den MySQL-SQL Dialekt.

Hab ich aber so ausm MySQL-Buch abgeschrieben... *schmoll*

Hier bringt er zwar keine Fehlermeldung, und fürht das auch aus, aber MySQL fügt nur neue Datensätze hinten an... geänderte Datensätze existieren ja quasi schon (wenn auch noch nicht geändert), also lässt MySQL sie aus.  (Denk ich mir so, obs auch so ist???)
Kann das vielleicht an der Syntax liegen, so wie Du gesagt hast?

Was folgerst du aus dieser Aussage?
Fazit: Codebeispiel, Queries und Fehlermeldungen posten. Danke.
Viele Grüsse
Philipp

Der Schleier ist soweit drunten, hoff ich..  ;-)

Grisse
Christian

[Philipp Hasenfratz]

Halihallo Christl

Fehlermeldung? - Beispiel eines Queries, der (den|die) Fehler verursacht. Ich vermute,
dass ODBC entweder deine Eingabe nicht versteht (Syntax des Queries), oder dass MySQL
den Query (wiederum Syntax) nicht versteht.

Hm, das exportierende Büro-/Lagerverwaltungsprogramm (BLVP) bringt einfach nur eine Zugriffsverletzung unter Adresse 0000000000... Kann man nix mit anfangen...

Oh, juhee...??? - Ich liebe Windows...
Also du hast ein fertiges System namens BLVP, welches über eine ADO-Datenquelle die
Daten in eine MySQL Datenbank exportiert? - Kannst du die Queries irgendwie ansehen,
die da getätigt werden? - Gibt's soeine Funktion wie Dump, welcher die Daten als
SQL-Statements in eine Datei auslagert?

Ich habe den MySQL-ODBC-Treiber unter Win2000 installiert, und öffne im BLVP unter "exportieren" die MySQL-Datenbank als ADO-Datenquelle. Bis dahin läuft alles. Ich kann auch exportieren, d.h. die Datensätze (über 25000) werden einfach hinten angehängt, das BLVP überschreibt die Datei einfach nicht.. (oder updatet auch nicht..)

Lässt sich BLVP nicht konfigurieren? - Das ist ja grausam. Ich denke mal, dass du dann
schlechte Karten hast, wenn du die Synchronisation/Export nicht beeinflussen kannst.

Da dieser Export auch ein bischen dauert (so 20 - 25 min) kann man in der Zeit ja auch nicht zugreifen...

Wieso nicht? - Verweigert dies ADO/ODBC?

Nun, dann zieh den Schleier aus und lies uns die Fehlermeldung vor.
Mit einem Schleier vor dem Haupt lässt sich bekanntlich schlecht Programmieren (es sei
denn der Computer liest dir alles vor)... :-)

REPLACE tabelle_1 (Feld_1, Feld_2, Feld_3) SELECT Feld_1, Feld_2, Feld_3 FROM tabelle_2 ORDER BY Feld_1

Und was soll MySQL damit anfangen? - Das mag ODBC bzw. SQL konform sein, nicht jedoch
für den MySQL-SQL Dialekt.
Hab ich aber so ausm MySQL-Buch abgeschrieben... *schmoll*

Ein REPLACE ist kein UPDATE. REPLACE ist (fast) äquivalent zu DELETE und INSERT. Nun gut,
was hat das mit dir zu tun? - Ich glaube, dass du auf der Tabelle tabelle_1 keinen
Primary Key hast und dann kann MySQL keinen Update ausführen, sondern INSERTED einfach
alle Records. Definiere einen Primary Key auf dieser Tabelle und dir werden die Records
"updated", wobei du hier vorsichtig sein musst, wenn du AUTOINC-Spalten benutzt:
Die ID's wachsen mit jedem REPLACE (da es eben kein UPDATE, sondern ein DELETE+INSERT
ist.).

Hier bringt er zwar keine Fehlermeldung, und fürht das auch aus, aber MySQL fügt nur neue Datensätze hinten an... geänderte Datensätze existieren ja quasi schon (wenn auch noch nicht geändert), also lässt MySQL sie aus.  (Denk ich mir so, obs auch so ist???)
Kann das vielleicht an der Syntax liegen, so wie Du gesagt hast?

In diesem Falle nein, es ist ein datenbanktechnisches Problem; MySQL braucht einen
Primary Key auf der Tabelle, um die Records unterscheiden zu können. Wie sonst soll
MySQL wissen, welcher Eintrag REPLACED werden soll?

Der Schleier ist soweit drunten, hoff ich..  ;-)

Bei mir war und ist er es, wie siehts bei dir jetzt aus?

Viele Grüsse

Philipp

[Christl]

Halihallo Christl
Oh, juhee...??? - Ich liebe Windows...
Also du hast ein fertiges System namens BLVP, welches über eine ADO-Datenquelle die
Daten in eine MySQL Datenbank exportiert? - Kannst du die Queries irgendwie ansehen,
die da getätigt werden? - Gibt's soeine Funktion wie Dump, welcher die Daten als
SQL-Statements in eine Datei auslagert?

Kurz und bündig: nö.   ;-)

Lässt sich BLVP nicht konfigurieren?

Wieder: nö.

Wieso nicht? - Verweigert dies ADO/ODBC?

*grins*: nö!
Aber das BLVP meldet sofort eine Zugriffsverletztung unter Adresse xyz, wenn die Datenbank auch nur aufgemacht wird...

Ein REPLACE ist kein UPDATE. REPLACE ist (fast) äquivalent zu DELETE und INSERT. Nun gut,
was hat das mit dir zu tun? - Ich glaube, dass du auf der Tabelle tabelle_1 keinen
Primary Key hast und dann kann MySQL keinen Update ausführen, sondern INSERTED einfach
alle Records. Definiere einen Primary Key auf dieser Tabelle und dir werden die Records
"updated", wobei du hier vorsichtig sein musst, wenn du AUTOINC-Spalten benutzt:
Die ID's wachsen mit jedem REPLACE (da es eben kein UPDATE, sondern ein DELETE+INSERT
ist.).

Hm, genau das ist ja das "Grande Malheur du Kack": wenn ich in der Tabelle, in die exportiert wird, einen Key angebe, bringt auch das eine Zugriffsverletzung, da das BLVP einfach nur Daten rausschiebt, aber keinerlei Prüfung/Update o.ä. macht...

Ne weitere Möglichkeit wäre, das ganze als .rtf-Format zu exportieren, solche Dateien überschreibt das BLVP einfach... Ist dann nur noch das Problem, wie ich den Import aus einer Textdatei "automatisieren" kann.... Das Ganze soll ja mal auf einem Webserver liegen, wenn ich dann jeden Tag 2345..x manuell aktualisieren muss...
Prost Mahlzeit!

Fällt Dir vielleicht noch ein anderer Lösungsweg ein?
Bitte, bitte!

Grisse
Christl

[Philipp Hasenfratz]

Halihallo Christl

Fällt Dir vielleicht noch ein anderer Lösungsweg ein?
Bitte, bitte!

Kurz und bündig: nö :-))   [ich würde dennoch weiterlesen ;)]

Hm, genau das ist ja das "Grande Malheur du Kack": wenn ich in der Tabelle, in die exportiert wird, einen Key angebe, bringt auch das eine Zugriffsverletzung, da das BLVP einfach nur Daten rausschiebt, aber keinerlei Prüfung/Update o.ä. macht...

Also wenn du das Problem auf lange Sicht gut lösen willst, würde ich der Herstellerfirma
mal eine entsprechende Nachricht hinterlassen... kurzfristig:

Ne weitere Möglichkeit wäre, das ganze als .rtf-Format zu exportieren, solche Dateien überschreibt das BLVP einfach... Ist dann nur noch das Problem, wie ich den Import aus einer Textdatei "automatisieren" kann.... Das Ganze soll ja mal auf einem Webserver liegen, wenn ich dann jeden Tag 2345..x manuell aktualisieren muss...

Ob es noch andere Lösungsmöglichkeiten gibt, hängt weitestgehend davon ab, was _du_ haben
willst/musst. Brauchst du eine ständig aktuelle Version im Web? - Wie oft soll
Synchronisiert werden? - Gibt es andere Exportmöglichkeiten (neben ADO, RTF)? - Wie
umfangreich sind die Datenmengen?

Folgendes fällt mir als Lösungsmöglichkeiten noch ein:
 - Eine Zwischentabelle, wie du es vorgeschlagen hast, ohne Primary Key, die Daten
   werden dann über ein Sync-Programm mit der "Internet-Abbildung der DB" synchronisiert
   (dort kanns ja dann einen Primary geben)
 - Du versuchst die Queries zu ändern (du hast ja verneint, dass man das System nicht
   konfigurieren kann) und zwar derart, dass sie funktionieren. Vielleicht bringt ein
   umstellen etwas, oder ein UNIQUE-Index auf die Attribute, die Primaries sein sollten.

Ich muss grad aus'm Büro, werde nochmals darüber nachdenken. Inzwischen kannst du ja
etwas erleutern, was du _genau_ brauchst (s. Fragen oben).

Viele Grüsse

Philipp

[Christl]

Habediere Philipp!

Also wenn du das Problem auf lange Sicht gut lösen willst, würde ich der Herstellerfirma
mal eine entsprechende Nachricht hinterlassen... kurzfristig:

Naja, der "Suppenport" ist auch so wie er heisst...

Ob es noch andere Lösungsmöglichkeiten gibt, hängt weitestgehend davon ab, was _du_ haben
willst/musst. Brauchst du eine ständig aktuelle Version im Web? - Wie oft soll
Synchronisiert werden? - Gibt es andere Exportmöglichkeiten (neben ADO, RTF)? - Wie
umfangreich sind die Datenmengen?

Also denn:
Das BLVP benutzt Datenbanken mit Endung: .bpd (keine Ahnung was das für eins ist...), ich hab aber auch keine Ahnung welche Daten in welcher .bpd-Datenbank liegen.... Insgesamt: 148 Datenbanken mit 9,3 GB Daten.. Viel Spaß beim suchen  ;-))
Exporte sind möglich in folgenden Formaten:
.rtf, .txt (als ASCII oder ANSI), .xls (´95 und ´97), dBase (welche Version weiss allein der Herr) und über die ADO-Schnittstelle auf ODBC.
Also ist Access auch ansprechbar, aber auch hier fügt BLVP die Daten nur an und updatet nicht. somit bietet Access keinen Vorteil, im Gegentum, es ist ja nicht für Webserver gedacht.

Es soll jeden Tag aktualisiert werden.
Die exportierten Daten haben ungefähr eine Größe (im .rtf-Format) von ca. 10 - 25 MB (je nachdem, welche Adressengruppen ich wähle). Als Webserver steht ein Monster nur für mich allein zur Verfügung: 2,xx GHz, 1,xx GB RAM und 60 GB-Platte... Sollte reichen..
(mir fällt da bloß der Spruch: "mit H-Bomben auf Spatzen losgehen" ein)

Folgendes fällt mir als Lösungsmöglichkeiten noch ein:
 - Eine Zwischentabelle, wie du es vorgeschlagen hast, ohne Primary Key, die Daten
   werden dann über ein Sync-Programm mit der "Internet-Abbildung der DB" synchronisiert
   (dort kanns ja dann einen Primary geben)
 - Du versuchst die Queries zu ändern (du hast ja verneint, dass man das System nicht
   konfigurieren kann) und zwar derart, dass sie funktionieren. Vielleicht bringt ein
   umstellen etwas, oder ein UNIQUE-Index auf die Attribute, die Primaries sein sollten.

Das mit dieser Zwischentabelle versuch ich gerade: Export in Tabelle_2 und dann Tabelle_1 updaten (Wobei ich die Tabelle_2 ihres Schlüssels beraubt habe und Tabelle_1 einen Unique besitzt)

Viele Grüsse

Philipp

Grisse
Christian

[Philipp Hasenfratz]

Halihallo Christl

Das BLVP benutzt Datenbanken mit Endung: .bpd (keine Ahnung was das für eins ist...), ich hab aber auch keine Ahnung welche Daten in welcher .bpd-Datenbank liegen.... Insgesamt: 148 Datenbanken mit 9,3 GB Daten.. Viel Spaß beim suchen  ;-))

Nun denn, also internes Zeug, da ist die Wahrscheinlichkeit klein auf die Daten direkt
zuzugreifen...

.rtf, .txt (als ASCII oder ANSI), .xls (´95 und ´97), dBase (welche Version weiss allein der Herr) und über die ADO-Schnittstelle auf ODBC.

Nun ja, mit txt kann man ja schnell was solides erstellen, wenn die Daten in einem
vernünftigen Format abgelegt sind. Da bräuchte man ein kleines Script, welches die Daten
aus der .txt extrahiert und in der DB speichert.

Also ist Access auch ansprechbar, aber auch hier fügt BLVP die Daten nur an und updatet nicht. somit bietet Access keinen Vorteil, im Gegentum, es ist ja nicht für Webserver gedacht.

ACK.

Es soll jeden Tag aktualisiert werden.

cron-job oder für Windows "Geplante Tasks" oder wie das Ding heisst; dann kannst du den
Traffic der Sync auf niederfrequentierte Zeiten (eg. falls der Server auch als HTTP-
Webserver fungiert) auslagern.

---

Also, ein Export in exotische Dateiformate, wie xls oder Access würde ich vermeiden.
Vorziehen würde ich .txt, da diese mit einer 4th Generation Language (Perl/PHP/ASP/VBS)
einfach zu behandeln sind. Die Datenbankanbindung kriegst du mit allen Sprachen gleich
mit. Dieses Vorgehen wäre eine Möglichkeit.
Du sagst, du möchtest die Daten einmal täglich aktualisieren. Machst du dies per Hand,
oder lässt sich dein System automatisch dazu veranlassen? - In jedem Fall ist dies ein
Bonus der dir zu gute kommt, da eine RealTime-Synchronisation der Daten im gegebenen
Kontext wohl fast verunmöglicht wird. Ich glaube, dass es kein Problem wäre hier mit
einer Zwischentabelle zu arbeiten, welche temporär alle Daten speichert. Die UPDATE's
würde ich, weil dein System sie anscheinend nicht richtig umsetzen kann, in ein
Script auslagern, welches die Daten von dieser Zwischentabelle nimmt und sie in die
Datenbank einfügt, welche vom Internet aus ansteuerbar ist.
Die beste Lösung wäre wohl immer noch, dass du dein System irgendwie dazu veranlassen
kannst, mit Primary Keys richtig umzugehen, wenn dies jedoch einfach nicht will, solltest
du in Erwägung ziehen diese Arbeit über eine selbstprogrammierte Middleware zu
realisieren.

Etwas konkreter:
Du lässt BLVP die Daten in die Tabelle ohne Primaries exportieren, dann wird ein Script
gestartet, welches diese Daten ausliest und einen REPLACE auf die Tabelle mit Primary
ausführt und nach Abschluss dieser Synchronisation die erstgenannte Tabelle komplett
leert (um beim nachsten Export keine doppelten Einträge zu haben).

Falls die exportierte .txt Datei eine einfache Struktur aufweist (eg. CSV) könntest du
auch ganz auf Scripts verzichten und versuchen die .txt per SQL-Statement in die DB
einzulesen.

Falls du mit dem Versucht BLVP->TabelleMitPrimary nicht erfolgreich bist, bleibt meiner
Meinung nach nur der Umweg über manuelle Arbeit oder der Automatisierung über ein Script.
Es sei denn, jemand kennt eine geeignete, bestehende Middleware; ich kenne leider keine.

Viele Grüsse

Philipp