DB-Problem

[Andi]

Hallo,

uns ist was aufgefallen:

Wir entdeckten heute bei einem Artikel einen
Fehler (Schreibfehler in der Artikelbeschreibung) und
wollten diesen korrigieren.
Nach unzähligen Uploadversuchen stellten wir fest, das
die Änderung (anscheinend) nur nach Neuanlage der
Server-DB übernommen wurde.

Eigentlich ja nicht so schlimm - jedoch wird
ja auch alles andere auf der Server-DB gelöscht ?
Nun wäre das sehr fatal - da wir doch unseren neuen
Shop durch SP_Forms Features total auf solche Dinge wie
Kundenkonto selbst erstellen, Favoritenliste usw.
getrimmt haben. Was nützt z.B. die Merkliste, wenn die
andauernd gelöscht wird....



Freundliche Grüße
Andi


Linkback: https://www.shoppilot.net/pf/index.php?topic=148.0

[emil]

Hallo Andi,

das Problem mit einzelnen Hängern bei der Replikation bei Änderungen habe ich auch schon beobachtet. So recht war das nicht eingrenzbar und demzufolge auch nicht nachverfolgbar.

Deshalb sicherheitshalber, und bei Strukturveränderung innerhalb des Shops sowieso, erstelle ich relativ oft die DB auf dem Server neu. Da ist man immer auf der sicheren Seite. Bei der Komplettreplikation gab es noch nie Schwierigkeiten, mal abgesehen, man hat mal selbst was verzapft, wie dopelte Artikelnummern oder unzuläßige Sonderzeichen und Umlaute.

Aber zu Deiner Frage:

Normalerweise wirst Du nach dem Erstellen der Stammtabellen gefragt, ob Du auch die Bewegungsdaten löschen willst (weiß nicht genau wie das dort steht). Du kannst auch in der Spilot.ini mit dem Parameter allow-delete-favorites=no dieses Löschen generell unterbinden, mußt es allerdings bei Neueinrichtung eines Shops mal kurz mit yes freigeben.

Viele Grüße
Emil
 

[Andi]

Oh Danke >>emil<< für den Hinweis.

Wusste ich gar nicht, das man in der spilot.ini
sowas einstellen kann.
Wenn ich das richtig verstehe, wird dann auch bei
Neuanlage der DB auf dem Server die Favoritenliste
NICHT mehr gelöscht.. das ist doch schon was  


Das mit der unvollständigen Replikation beobachte
ich schon seit langer Zeit - was aber bisher nicht so
wichtig, da das mit den Kundenkonten etc. bei
uns noch nicht so die Rolle spielte (im Shop).

Danke und Grüße
Andi

[hop]

Hallo Andi,

die Favoritenliste wird in keinem Fall automatisch gelöscht.
Es gibt zumindest immer eine Abfrage. Oder man verbietet
das Löschen generell (wie emil geschrieben hat).

Fehler bei der Replikation haben immer eine Ursache.
Ob Fehler aufgetreten sind, kann man im Protokoll der
Replikation feststellen hier sollte am Ende 0 Fehler
stehen. Wenn das nicht der Fall ist, haben einige
SQL-Statments Fehler zurückgeliefert.

Ursachen können z.B. sein:
Doppelter Primäschlüssel, ich habe z.B. einen Kunden oder
Artikel der zwei mal vorhanden ist.
Kommunikationsprobleme mit der Datenbank.


Es gibt noch eine weitere Fehlerursachen:
Änderung eines Primärschlüssels
Habe ich einen Artikel mit der Nummer 4711 und ändere die
Artikelnummer in 4712. Kann der Artikel 4711 nicht aus der
Datenbank gelöscht werden. In diesem Fall muss die DB
neu angelegt werden. ShopPilot gibt in diesem Fall
ausdrücklich eine Warnmeldung aus. Im Handbuch ist
beschrieben welche Primäschlüssel es für die einzelnen
Objekte gibt.

Bei sehr grossen Änderungen empfiehlt sich die Neuanlage
der DB, weil dass schneller geht als die Replizierung.
Faustregel, wenn über 50% aller Objekte (Artikel) geändert
wurden ist die Neuanlage besser. Wenn ich Artikel von einer
Seite in eine andere Seite verschiebe bedeutet dies eine
Änderung, da der Artikel ja die Seitennummer beinhaltet.


Falls Problem bei der Replizierung auftauchen, können wir
helfen, wenn wir das Fehlerprotokoll erhalten und eine
Beschreibung der Änderung die durchgeführt wurde.

hop

[Andi]

Hallo >>hop<<,

mir war bisher nicht bewusst, das man - wenn
man die DB erstellt - auch NEIN sagen kann.
Ich dachte immer, das dann der Vorgang abgebrochen wird.

Na ja immer die Datenbankgeschichten...

Trotzdem klappt das mit der Replikation nicht immer.
Da wir (jetzt) mit Preisen in den Subkatalogen arbeiten,
kann man jetzt immer gut sehen, ob den Artikel doppelt
vorhanden sind (diese sind dann ohne Preis in den Sub`s).
Ob irgendwelche Kommunikationsprobleme auftreten, müssen
wir weiter beobachten - jedoch ist doch eine Änderung
in der Beschreibung eines Artikels kein Grund, die
Server DB neu anzulegen (so wie es heute war).

Aber manchmal sieht man ja den Wald vor Bäumen nicht,
eventuell übersehen wir ja auch wieder mal was.

Friede mit Euch allen  

Andi

[jg]

> Trotzdem klappt das mit der Replikation nicht immer.
> Da wir (jetzt) mit Preisen in den Subkatalogen arbeiten,
> kann man jetzt immer gut sehen, ob den Artikel doppelt
> vorhanden sind (diese sind dann ohne Preis in den Sub`s).
> Ob irgendwelche Kommunikationsprobleme auftreten, müssen
> wir weiter beobachten - jedoch ist doch eine Änderung
> in der Beschreibung eines Artikels kein Grund, die
> Server DB neu anzulegen (so wie es heute war).

Hallo Andi,

auch bei uns gibt es hin und wieder Probleme mit der
Replikation der DB, die unserer Erfahrung nach aber nicht
immer nur auf SP zurückzuführen sind.
Machen wir in unserer Warenwirtschaft (->WW, bei uns sind
das zB. dBase-Tabellen) ein Feld einfach leer, so übernimmt
SP nicht den leeren Inhalt dieses Feldes, sondern lässt den
alten Inhalt einfach stehen. Das weiss der Support aber und
ich hoffe, sie korrigieren das mit der 2.0 ...
Wie übernehmt ihr denn eure Daten in SP? Bei uns werden
Abfragen aus Access übernommen, Access seinerseits zieht
sich die Daten per ODBC aus besagten dBase-Tabellen.
Hier klappt auch bei uns das Zusammenspiel nicht immer
richtig. Manchmal passiert es tatsächlich, dass Art.-Beschreibungen
in der WW geändert werden und dann nach dem
Update (wie bei euch) online nicht zu finden sind.
Auch stimmt manchmal die Anzahl der lokal eingelesenen
Subk-Artikel nicht mit der Anzahl überein, die ich in der
MySQL-DB finde. Wir haben 'unsere Ursache' dafür gefunden:
Eine REORGANISATION der WW-DB (oder der entsprechenden
Tabelle) und ein Reparieren und Komprimieren der Access-DB.
Dann werden alle geänderten Inhalte auch richtig in SP
eingelesen und übertragen. Wenigstens funktioniert das bei
uns immer dann, wenn es die von dir beschriebenen Probleme gibt.
Die DB in SP müssen wir nur noch sehr selten komplett
neu übertragen. Willkürliche Fehler von SP (bis auf einige
bisher von mir beschriebene) kann ich nicht bestätigen,
und wir arbeiten 8-10 Stunden pro (Werk)Tag mit SP-EP.

> Da wir (jetzt) mit Preisen in den Subkatalogen arbeiten,
> kann man jetzt immer gut sehen, ob den Artikel doppelt
> vorhanden sind (diese sind dann ohne Preis in den Sub`s).
Seitennummer richtig zugeordnet? Wenn in der WW eine
andere Seitennummer steht als in SP wird der Artikel
doppelt angelegt.

Ansonsten musst du genau analysieren, wo wann was nicht
übernommen wird. Fehler lassen sich finden, auch wenn das
im Zusammenspiel mit unterschiedlichen Datenbanken nicht
immer einfach ist.

Grüße jg

[Andi]

Hallo JG


wir administrieren (pflegen) unseren Shop
ausschließlich direkt mit ShopPilot.
Leider ist unsere WW recht Speziell für unsere
Niederlassung programmiert (für die Bedürfnisse
einer lokalen Kfz-Firma) und überhaupt nicht
für E-Commerce usw.

Die Programmierer (der WW) sind leider auch solche
"Blindnieten", das nicht einmal bisher die Möglichkeit
geschaffen werden konnte, die Daten aus SP (artikel)
wenigstens in die WW zu importieren.

Trotzdem DANKE für Deine ausführliche Message !!!

Viele Grüße
Andi  

[jg]

> wir administrieren (pflegen) unseren Shop
> ausschließlich direkt mit ShopPilot.

Oh Mann, da solltet Ihr aber langfristig eine Verbindung
zwischen WW und SP herstellen. Ich weiß wie schwer das ist.
Wir hatten auch mal eine Zeit, da haben wir täglich
doppelt aktualisiert, einmal WW einmal SP. Da konnte
ich fast einen Mitarbeiter zusätzlich beschäftigen.
Wenn aber die Verbindung einmal steht, fängt die Sache an
so richtig Spasss zu machen. Und der Vorsprung ggü.
der Konkurrenz ist euch dann auch sicher...
 

> Leider ist unsere WW recht Speziell für unsere
> Niederlassung programmiert (für die Bedürfnisse
> einer lokalen Kfz-Firma) und überhaupt nicht
> für E-Commerce usw.
Unsere WW ist eine alte DOS-Kiste mit dBase2-Tabellen.
Seit 1993 wurden nur noch die notwendigsten Updates
gemacht. Jede Software-Firma belächelt uns, logisch.
Aber das stört uns nicht. Die Sache läuft und Bestellungen
über unseren Shop kommen auch jeden Tag. Ergebnis zählt.

jg

[Andi]

Hallo JG

so ne alte "DOS-Kiste" haben wir auch :rolleyes:

Gibts da denn irgendwelche Import-Tools ??
Da ja die Firma, die das Programm erstellt hat
sich nicht im geringsten darum schert, kann man
ja eventuell selber was machen...
..ist bestimmt Wunschdenken...


Grüße
Andi

[jg]

> so ne alte "DOS-Kiste" haben wir auch

Wie heisst denn eure Artikel-Datei (Tabelle) in der WW?
Das kann doch nicht so schwer sein, die über Access mit
SP zu verbinden. Arbeitet und aktualisiert ihr die WW
täglich? Kannst mich ja auch mal anrufen...

jg

[emil]

Hallo hop, hallo Ihr Alle,

Au wei, jetzt habe ich aber einige Fettnäpfchen mitgenommen.

Ich will mal versuchen das Problem einzugrenzen:

1. Werden Artikel in der Quelldatenbank verschoben oder gelöscht, müßte man sie erst mit Löschbefehl importieren etc. Wenn man aber einfach die Seitenzahl ändert oder den Artikel löscht, hat man das Problem, daß das Shoppilot beim Aktualisieren nicht mitbekommen kann. Logisch und kein Problem von SP. Hier hilft eigentlich nur manuelles Löschen oder Neuimport.

2. Sind Änderungen - nur dann - in SP vorgenommen worden (manuell oder durch Import) und wurde der Shop abgespeichert, kommt es in seltenen Fällen vor, daß einzelne Änderungen nicht per Replikation im Web ankommen. Warum, konnte ich leider bisher nicht eingrenzen. Doppelte Artikelnummern möchte ich hier ausschließen.
Jedenfalls steht nichts entscheidendes im Replikationsprotokoll.

Und Hop weiß, daß ich hier schon ganz klar die Karten auf den Tisch lege, ich laß es nicht bloß beim "geht nicht".

Ich möchte hier ausdrücklich feststellen, daß die Replikation im Regelfall ordentlich funktioniert. Aber es scheint seltene hartnäckige Einzelfälle zu geben, die manchmal doch zu einer gewissen Unsicherheit führen.

Vielleicht sollten wir, wenn wir mal wieder so was beobachten, gezielter nach der möglichen Ursache suchen.


Und um das effektiver zu machen, wüßte ich gern, wo und wie lokal abgespeichert wird, daß der Datensatz repliziert werden muß, und wann das Kennzeichen zurückgesetzt wird. Damit man mal selbst nachsehen kann.

Könnte es vielleicht sein, daß das Kennzeichen zurückgesetzt wird, ohne daß auf Einzel-Erfolg gewartet wird? Und da könnte ja schon einen kleine Netzinstabilität Ursache sein.
Aber das ist reine Spekulation, würde aber bestätigen, daß eine erneuter Replikationsversuch nichts bringen kann. Vielleicht bringt uns das schon weiter.


Viele Grüße
Emil

[hop]

Hallo Emil,

in der 2.0 haben wir jetzt eingebaut, dass Fehler bei der Replikation in der Datei pilotlog.txt festgehalten werden.
Die Datei liegt im Projektverzeichnis eines Enterprise-Shops.

Falls also irgendwann wieder ein Fehler auftritt, könnten wir anhand der Logdatei feststellen, was passiert ist, hoffe ich jedenfalls. Zumindest kämme man der per Eingrenzung der Fehlerursache ein gutes Stück näher.

hop

[emil]

Hallo Hop,

danke. Aber das direkte Protokoll aus dem Replikationsfenster ist nicht irgendwo abgeseichert?
Manchmal sieht man da kurz was stehen, mit "weiter" ist alles weg.

Viele Grüße
Emil

[hop]

Hallo Emil,

wir haben zuerst mal nur Fehler in der logdatei abgespeichert, weil ansonsten die Datenmenge zu gross wird
und man den Überblick verliert.

Ich gehe davon aus, dass das Problem mit einem SQL-Statment zusammenhängt, das einen Fehler zurückliefert, insofern müsste es reichen nur evtl. Fehler in der Logdatei aufzuzeichnen.

hop

[DS]

Hallo Allerseits,
das Problem mit der Datenbank haben wir bei einem Projekt auch: Änderungen in Artikelbeschreibung erfordern sehr häufig  das Neuanlegen der DB. Ich konnte das Problem bisher auch nicht weiter eingrenzen.

Nun ist aber ein neues Problem dazugekommen: einige neue Artikel werden trotz Neuanlegen der Datenbank einfach nicht angezeigt. Komischerweise werden andere Artikel der Produktgruppe einwandfrei angezeigt. Hat das vielleicht jemand anders auch schon beobachtet?

Wäre für jeden Lösungvorschlag dankbar. Ach ja, es kommt die Version 1.5.10 zum Einsatz.

MfG
DS