Beitrag von hempelr (1976 Beiträge) am Samstag, 22.Februar.2003, 08:20.
@CB - "Kleine" Ergänzung zur BP-Bedienung!??!
Hallo, Christoph
da es mir in den vergangenen 2 Wochen mehr als einmal (wenn ich ehrlich bin fast täglich einmal) passiert ist, daß DB's nach Änderungen plötzlich total zerschossen sind (also riiieeesengroß trotz dass nur ein DS drin steht und kein Inhalt mehr in der BP-Oberfläche sichtbar - übrigens auch nicht mittels get "holbar") wäre es (vielleicht) ein guter und wichtiger Plan, in die "bedienungsseite" bei den Datenbanken zum einen die Anzeige der Größe der DB mit einzubauen und zum anderen den Link für ein Reorg.
Folgende Begründung:
Bei mehrfachem Ändern von DB-Inhalten hintereinander innerhalb der BP-Oberfläche legt BP von jedem Datensatz Sicherungsdatensätze in seiner internen Inhalts-Struktur an. Nun erfolgt aber leider die Erkennung Unterscheidung ob Sicherungsdatensatz oder gültiger Datensatz offensichtlich durch das Zeichen "°"; das auf welche Art auch immer beim Speichern generiert wird.
Ich habe nun festgestellt, daß dieses Sonderzeichen auch noch komischerweise an manchen Stellen im Feldinhalt auftaucht, wo (bei meinem speziell untersuchten Falle wenigstens) im Feldinhalt Perl-Quelltext steht (soll mittels eval in nem Template-Code ausgeführt werden) und eine Derefernzierung auf eine Var / Interpolation mit einer Rechenoperation auf eine BP-Interne Funktion stattfindet und mittels eines Backslashes das Sonderzeichen & zur Ausgabe maskiert wurde.
Wenn aber vor der Änderung die DB jedesmal neu reorgt wird, dann tritt dieser Fehler nicht auf (logo - werden ja die Sicherungsdatensätze gelöscht) und die DB wird auch nicht zerschossen.
Eckdaten zu den Inhalten der DB wo das immer wieder passiert: 5 Datenfelder, davon 2 normale Textfelder mit nur paar Worten Inhalt, 3 Felder für Perl-Quelltext jeweils so etwa 5-10 KB Text; wenn reorg gemacht Gesamtdb ca. 40 KB gross, nach 2maliger Änderung der "grossen" Felder ca. 250 KB gross und dann irgendwann bei nochmaliger Änderung der "Overkill".
Wenn man nun in der Inhalts-Übersichtsseite der DB gleich die Größe sehen würde könnte man vor dem Overkill reagieren und gleich mal nen reorg machen und dann erst ändern. So muß man jedesmal erst ganz zurück in die Verzeichnisanzeige - Größe der DB überprüfen - DB-Inhaltsseite wieder aufrufen - in Verwaltung gehen - reorg machen - zurück in Inhaltsseite - Datensatz zum ändern aufrufen - Änderungen machen - abschicken (uuuupps - ganz außer Puste bei soviel Stufen rauf und runter auf der Treppe :-))
Oder hast du vielleicht ne Idee, wie sich der "Overkill" generell vermeiden ließe? Ich werds mal weiter im Auge behalten und wenns wieder ne Datenbank zerschossen hat diese runterladen und analysieren (hab bisher noch keine zerschossene angeschaut - war jedesmal einfach nur erschrocken und bischen sauer)
Hoffe, du kannst das Prob irgendwie lösen
Ruben
Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 24.Februar.2003, 13:35.
Re: @CB - "Kleine" Ergänzung zur BP-Bedienung!??!
Ich würde dann lieber den Fehler ausbessern, der zu den kaputten DBs führt - wenn ich es richtig verstanden habe, kannst Du den Fehler (mehr oder weniger?) reproduzieren? Bin aus Deiner Beschreibung noch nich so ganz schlau geworden, vielleicht können wir das (per Email?) genauer einkreisen. Also am liebsten wäre mir ne genaue Schritt für Schritt Beschreibung, was ich tun muss, um ne DB zu zerschiessen ;-)
Beitrag von hempelr (1976 Beiträge) am Montag, 24.Februar.2003, 17:21.
Re: @CB - "Kleine" Ergänzung zur BP-Bedienung!??!
Näheres kommt per mail - passiert unterdessen täglich mehrmals, daß die db sich verabschiedet......
muß aber erst mal noch paar Dinge zu Ende bringen, kopier solang die dbs immer....
ruben
