multiple rows in singleton select

[hanspeter]

Hallo,

beim Versuch eines Updates

SQL-Code:

UPDATE START
 SET MARKPT=' '
 WHERE SID=3208

bekomme ich die Fehlermeldung

multiple rows in singleton select


Mit Select * from Start WHERE SID=3208 bekomme ich aber nur eine Antwortzeile.
BackUp / Restore hat auch nichts gebracht.
Wo kann ich noch suchen ?

Gruß
Peter

[faux]

ev. hilft hier noch ein LIMIT 1?

Grüße
Faux

[chaosben]

Hi tu oll!

Überprüfe mal die Trigger, die bei diesem Update zuschlagen. Eventuell ist das was schief gelaufen.

[hanspeter]

So wie es aussieht war die Datenbank kaputt.
Dummerweise konnte der Fehler nicht mit Backup und Restore behoben werden.
Das habe ich mehrfach versucht und dazwischen auch die Datenbank gelöscht.

Jetzt habe ich eine einen Tag alte Kopie der Datenbank aus dem normalen Backup verwendet und es
funktioniert wieder.
Das ist übrigens bei Firebird nicht das erste mal, dass mir die Datenbank bis zur
Unbrauchbarkeit zerschossen wird.
Nicht sehr häufig aber 1 bis 2 mal im Jahr.

Gruß
Peter

[Lemmy]

Hi,

ich habe FB seit einigen Jahren im Einsatz (Netzwerk bis zu 10 User und das bei 30-40 Kunden) und mir ist noch nie eine DB kaputt gegangen. Hast Du vielleicht das Laufwerk auf dem die DB liegt gespiegelt (automatische Spiegelung)? Kopierst Du die DB direkt (z.B. bei einem Backup)?

GRüße
Lemmy

[hanspeter]

Ja, das jetzt wieder verwendete Backup ist direkt kopiert (Backup erfolgt täglich automatisch).
Das ist allerdings auf meinem Entwicklungsrechner passiert.
Irgendwann nach dem Debuggen mit D2006 war dann die Datenbank zerschossen.
Der Debugger war irgendwo im Programm hängen geblieben. Passiert mir mit D2006 regelmäßig.
Eine nicht abgeschlossene Transaction sollte doch mit dem folgenden Programmstart erledigt sein.

Gruß Peter

[Lemmy]

Hi,

du machst also ein Backup der Datenbank, indem Du die Datei (*.fdb) einfach kopierst? Das ist natürlich absolut tödlich! So etwas darst Du niemals bei einem SQL-Server machen, denn es ist nie klar, ob der Server noch auf die DB zugreift. WEnn das der Fall ist, kann es passieren, dass Du die DB zerstörst. Ein korrektes Backup kannst Du nur durch die Verwendung der Admin-Tools machen, z.B. gbak oder die Admin-Komponenten (IBBackupService). Die Backupdatei kannst Du dann nach belieben kopieren.

Eine nicht abgeschlossene Transaktion ist bei weitem nicht mit einem neuen Programmstart erledigt:

Beim Start einer Transaktion fertig FB quasi eine "Kopie" der Daten an. Kopie ist in " weil es keine richtige Kopie ist, mehr ein View auf die Daten. Wenn nun eine weitere (oder entsprechend mehrere) Transaktion anschließend gestartet werden, muss die Info über diese eine Transaktion immer mitgeschleift werden. Das erfordert mit der Zeit einen immer höheren Aufwand, was sich mit der Zeit auf die Geschwindigkeit auswirkt. Solche Transaktionen kannst Du nur dadurch wegbekommen, wenn Du einen Backup-Restore Zyklus machst, dann werden die begonnenen und nicht beendeten Transaktionen weggelöscht.

GRüße
Lemmy

[hanspeter]

Zitat:

Zitat von Lemmy

Hi,

du machst also ein Backup der Datenbank, indem Du die Datei (*.fdb) einfach kopierst? Das ist natürlich absolut tödlich! So etwas darst Du niemals bei einem SQL-Server machen, denn es ist nie klar, ob der Server noch auf die DB zugreift. WEnn das der Fall ist, kann es passieren, dass Du die DB zerstörst. Ein korrektes Backup kannst Du nur durch die Verwendung der Admin-Tools machen, z.B. gbak oder die Admin-Komponenten (IBBackupService). Die Backupdatei kannst Du dann nach belieben kopieren.

Eine nicht abgeschlossene Transaktion ist bei weitem nicht mit einem neuen Programmstart erledigt:

Beim Start einer Transaktion fertig FB quasi eine "Kopie" der Daten an. Kopie ist in " weil es keine richtige Kopie ist, mehr ein View auf die Daten. Wenn nun eine weitere (oder entsprechend mehrere) Transaktion anschließend gestartet werden, muss die Info über diese eine Transaktion immer mitgeschleift werden. Das erfordert mit der Zeit einen immer höheren Aufwand, was sich mit der Zeit auf die Geschwindigkeit auswirkt. Solche Transaktionen kannst Du nur dadurch wegbekommen, wenn Du einen Backup-Restore Zyklus machst, dann werden die begonnenen und nicht beendeten Transaktionen weggelöscht.

GRüße
Lemmy

Ja das ist mir alles bekannt.
Ich habe ja ausdrücklich geschrieben, dass es sich um meinen Entwicklungsrechner handelt.
Vor dem Shutdown läuft automatisch ein inkrementelles Backup. - Da ist kein Server mehr aktiv.
Und das Problem der nicht abgeschlossenen Transaktionen habe ich wenn D2006, was leider häufiger vorkommt, beim Debuggen abstürzt.
Delphi muss dann neu gestartet werden.

Gruß Peter