Apache-Server & MySQL, phpMyAdmin & CRM-Tool - kann keine neuen Datensätze anlegen!

happy-drummer schrieb:
Wo genau steht das auf diesem Board hier? Habe die Regeln (sind ja nicht so viele Zeilen) gelesen, kann einen solchen Hinweis aber nicht finden.
Auf dem anderen Board steht es in der Tat und habe dort einen Hinweis eingefügt.

Ich habe bei meinen Smartphones beim Thema Root und Xposed auf verschiedenen Foren sehr unterschiedliche Erfahrungen gemacht. Auf einem kommt gar keine Antwort, auf einem anderen binnen zwei Tagen 10 Antworten.
Bei einem anderen Thema ist es umgekehrt.

Allein deswegen macht es aus meiner Sicht Sinn, eine Frage über verschiedene Kanäle zu stellen.
Zum Vergrößern anklicken....

Was ist das für eine lahme Stellungnahme?! Deine Erfahrung mit Forenantworten sind jetzt wirklich für niemand überraschend. Es war ja offenbar auch für Dich nicht der erste Tag im Internet. (Und kleiner Themenwechsel: Ein Forum ist keine Einbahnstraße, stellt man gute Fragen, bekommt man auch eher eine gute oder schlicht viele Antworten)

Parallelisierung ist in der IT eine tolle Sache, wenn man ein paar CPU Kerne hat, die eh nur rumidlen. Vor allem wenn es eigene CPU Kerne sind und man die Stromrechnung selbst bezahlt.
Hier reden wir aber von echten Menschen, deren Hilfsbereitschaft man nutzt! Es kann doch jenseits jeglicher Vorschriften nur so sein, dass man diese Hilfsbereitschaft fair nutzt und den Status Quo transparent macht. Also nicht dutzende Leute für sich arbeiten lässt, ohne als Mindestes mitzuteilen, dass an anderen Stellen die gleiche Frage gestellt wurde.

Hashtags dazu: Höflichkeit, Respekt, Gesunder Menschenverstand, ..
Dir fallen vielleicht selbst noch weitere ein.
 
Werbung:
@Kampfgummibaerlie, das glaube ich gerne. Je rechtzeitiger, desto besser. Da ich beruflich außer bezüglich meines CRM und meiner NUC (mit Kodi) nie viel mit Datenbanken zu tun hatte (zumindest nicht direkt: sicherlich nutze ich eine Reihe an Programmen, die intern eine Datenbank führen, doch bekomme ich da als Nutzer nichts von mit.), bin ich da nie tiefer eingestiegen und habe von PostgreSQL erst gestern im angepinnten Post dieser Untergruppe zum ersten Mal gelesen. Von daher bin ich jahrelang bei MySQL/phpMyAdmin hängengeblieben.
 
Neuer Zwischenstand: ich habe in einer nackten Datenbank im sauber aufgesetzten CRM nach und nach neue Kunden angelegt, bis ich in der Summe knapp 10 mehr hatte, als im derzeitigen Produktiv-CRM. Keine Probleme.

Ich werde nun mal aus der Datenbank nacheinander alle Tabellen - außer die Tabelle 'adressen' wiederherstellen und schauen ob ich nach jedem Einzelschritt die Tabelle 'adressen' erweitern kann.
 
akretschmer schrieb:
...enn diese Tabelle ist möglicherweise Ziel von Foreign Keys...
Zum Vergrößern anklicken....

Was bedeutet das? Ich bin kein Datenbank-Guru.

Bis jetzt geht es. Ich habe deutlich mehr Kundeneinträge als im Original, habe inzwischen Produkte, Preislisten und anderen einzelne Tabellen eingefügt und nach jeder einzeln eingefügten Tabelle einen neuen Kundendatensatz angelegt.
Bis jetzt klappt es... :)
 
Wenn ich das richtig verstehe, sollte das kein Problem darstellen, da der Aufbau der Tabellen in den Versionen des CRM grundsätzlich identisch ist. Oder sehe ich das falsch?

Das CRM hat in v.20.3 zwar einige Tabellen, welche die v.18.1 nicht hat. Doch diese Tabellen prüfe ich hinterher, ob sie einen Zusammenhang zu den Kundenkontakten haben. Scheint mir bisher nicht so.
 
akretschmer schrieb:
Ja.
Zum Vergrößern anklicken....

Das ist wieder einmal extrem hilfreich.

@happy-drummer Du zerstörst damit unter Umständen die Konsistenz Deiner Daten. Ein Datensatz existiert ja nicht ohne Abhängigkeiten. Ein Beispiel:

Reale Welt: Rechnung auf Papier.
Datenbank: Rechnung besteht zumindest aus einem Datensatz in einer Kopftabelle und einer Positionstabelle, oft auch noch mehr Tabellen. Wenn Du jetzt nur die Datensätze der Kopftabelle wiederherstellst, sieht unter Umständen in Deiner Software auf den ersten Blick alles ok aus, z.B. wenn die Software nur die Daten des Rechnungskopfes anzeigt. Sobald Du auf die Rechnung klickst wirst Du (hoffentlich) eine Fehlermeldung bekommen, im schlechtesten Fall werden aber beim bearbeiten Daten weiter zerstört.
 
Solange Du mit Kopien arbeitest, kannst Du natürlich so vorgehen und Dich an das Problem schleichen. Die kaputte DB kann man dann ja sorglos wegwerfen.
Ich wiederhole meinen Ansatz: Logfiles finden/aktivieren, dann Fehler provozieren und Log Files analysieren.
 
Walter schrieb:
Das ist wieder einmal extrem hilfreich.

@happy-drummer Du zerstörst damit unter Umständen die Konsistenz Deiner Daten. Ein Datensatz existiert ja nicht ohne Abhängigkeiten. Ein Beispiel:

Reale Welt: Rechnung auf Papier.
Datenbank: Rechnung besteht zumindest aus einem Datensatz in einer Kopftabelle und einer Positionstabelle, oft auch noch mehr Tabellen. Wenn Du jetzt nur die Datensätze der Kopftabelle wiederherstellst, sieht unter Umständen in Deiner Software auf den ersten Blick alles ok aus, z.B. wenn die Software nur die Daten des Rechnungskopfes anzeigt. Sobald Du auf die Rechnung klickst wirst Du (hoffentlich) eine Fehlermeldung bekommen, im schlechtesten Fall werden aber beim bearbeiten Daten weiter zerstört.
Zum Vergrößern anklicken....

Danke, @Walter! Sowas in der Art habe ich mir schon gedacht, dass der freundliche blaue Elefant sowas gemeint haben könnte.
Ist nachvollziehbar und logisch.
Dazu gleich mehr.
 
Da ich über zwei Foren Lösungsansätzen nachgehe und wie erwarte auch unterschiedliche kamen, hier ein kurzer Zwischenstand:

Ich hatte nach einem Hinweis (der eigentlich anders gemeint war) in der nackten Datenbank manuell ganz viele neue Datensätze angelegt. Alles ging ohne Probleme. Die IDs wurden sauber fortlaufend vergeben.
Insgesamt waren es am Ende etwa 10 Kunden mehr als im Produktiv-CRM.

Dann habe ich via mysqldumper einzelne Tabellen wiederhergestellt. Mit zwei Bildschirmen ging das wechselnd über mehrere Browsertabs recht flott.

Nachfolgende Tabellen habe ich dabei ausgelassen, da sie schon vom Namen her von einer Installation übergreifend auf einer anderen sicherlich Probleme bereiten könnten.

ID & Name
6. adresse
59. change_log
60. change_log_field
144. logfile
185. protokoll
187. prozessstarter
215. sqlcache
227. systemlog


Ich vermute mal, dass Du das meintest, @Walter?! Natürlich hat die Tabelle Bestellung mit dem Eintrag #xyz einen Bezug zur Tabelle Kunden mit dem Eintrag #abc. Ich bin aber als Laie davon ausgegangen, dass im Zweifel ein Feld einfach leer bleibt, wenn die zugehörige Tabelle noch leer ist.

Danach habe ich nach jeder Wiederherstellung einer einzelnen Tabelle im Tab des CRM einen neuen Kunden angelegt. Klappte immer ohne Probleme. Dann wieder ein paar Tabellen wiederhergestellt. Neuer Kunde im CRM. Klappte.
Dann habe ich die Tabellen 'adresse_accounts', 'adresse_kontakte' und 'adresse_rolle' einzeln wiederhergestellt. Jeweils dazwischen konnte ich neue Datensätze anlegen.

Ganz zum Schluss habe ich 'adresse' wiederhergestellt. Der Übersicht im Tab mit dem CRM hat sich nach F5 natürlich prompt verändert.

Nun habe ich einen neuen Datensatz anzulegen versucht. Ging nicht!

Als wäre die Tabelle 'adresse' korrupt. Wie bekomme ich das raus?

Im Log steht direkt nach dem versuchten Anlegen eines neuen Datensatzes nur
Code: 
Argumente der Funktion Protokoll:
 Array ( ) 
 Dump:
und das gleich 5x hintereinander.

Ich muss das mal mit einer nackten Datenbank testen, was dann im Log steht.
 
happy-drummer schrieb:
Da ich über zwei Foren Lösungsansätzen nachgehe
Zum Vergrößern anklicken....

Du solltest Dir erst einmal im klaren sein, woher der Name "relationales Datenbanksystem" kommt. Zwischen den Tabellen bestehen (meistens, nicht immer) Relationen, also Beziehungen. Ohne zu wissen, die diese definiert sind (also was sind PRIMARY KEYS, was Foreign Keys, welche weiteren CONSTRAINTS (check-constraints, not-null-constraints, exclusion constraints etc.)), wird mit hoher Sicherheit manuelles rumpfuschen, so wie Du es machst, das Chaos nur verschlimmern. Bereits in #2 wurde Dir gesagt, daß ohne tiefes Wissen, was Deine Applikation macht, Dir keiner helfen kann.
 
Werbung:
akretschmer schrieb:
Du solltest Dir erst einmal im klaren sein, ..Zwischen den Tabellen bestehen (meistens, nicht immer) Relationen, also Beziehungen. ..
Zum Vergrößern anklicken....
Dazu und den Zwischenergebnissen noch ein paar Hinweise:
Um die ganze Geschichte mit den Constraints/Relationen zu klären, sollte geprüft werden, ob überhaupt welche existieren. Wenn nicht, scheiden sie auch als Fehlerursache aus.
Wenn welche bestehen, kann man mit oder ohne Detailkenntnis der Constraints (Hauptsächlich Ref Constraints) einen offenen oder gezielten Test im defekten System durchführen:
- 1. Versuch, einen möglichst vollständigen Datensatz initial eingeben und speichern
- 2a. „bis letzte Woche“: Mglw. ist zu dem Zeitpunkt nichts kaputt gegangen, sondern es wurden nur "kaputte" Daten eingetragen (die Constraints verletzen). Also letzten Datensatz suchen, der „erfolgreich“ eingeben wurde, diesen merken und entfernen, neuen anlegen.
- 2b. Alternativ, diesen letzten Datensatz mit Daten gemäß Punkt 1 anreichern und erneut speichern bzw. die eingegebenen Daten auf Lücken, üblicherweise vorhandene, aber hier fehlende Daten prüfen und ergänzen.
- 3 die vorigen Schritte durch Betrachtung und Vergleich der betroffenen DS mit einem passenden Tool in der Tabelle begleiten

Worauf das hinausläuft: Es wurde zuletzt einfach etwas falsches oder unvollständiges oder ungültiges eingegeben. Fehlerhaftes Datum, fehlende Klassifizierung, ..
Ein direkter Vergleich der letzten Datensätze (Adresse, Kunde, ..) untereinander mit Datenbanktool und ohne die sicherlich unterschiedlichen Adressfelder sollte da dann etwas hergeben.

- 4 die oben aufgeführten Tabellen, die beim Test Transfer ausgelassen wurden, enthalten dem Namen nach ja offenbar auch spannende Daten (Change_log, Systemlog, ..) auch dort kann man nach Fehlern suchen, sowohl bei Neueingabe als auch zum Zeitpunkt des letzten funktionierenden Eintrags. (falls das nicht schon mit Log: ..array.. dump gemeint war. Allgemein ist es üblich, log Dateien mit Klartext zu füllen, jedenfalls sollte das bei MySQL so sein)
 
Zurück
Oben