PostgreSQL & Transaktionen

Hi,

ich habe folgenden (Pseudo-)Code:

	
PHP-Code:
	

		
			
...
BEGIN
$err = updateTable1();   
// update Table1 => führt UPDATE-Befehl aus und liefert FALSE wenn alles okay, TRUE bei Fehler
// hole andere Daten aus DB
$var = getResultOfQuery("SELECT * FROM anyTable");
if(!$err)
$err = updateTable1();    
// update Table2 => ührt UPDATE-Befehl aus und liefert FALSE wenn alles okay, TRUE bei Fehler
if(!$err)
COMMIT
else
ROLLBACK
... 



		
	

Problem ist, dass wenn das 1. update auf der DB schief geht, dann wird NICHTS mehr ausgeführt. Das der 2. update Befehl, bzw. Inserts nicht mehr gemacht werden ist klar, aber ich würde gerne noch Daten LESEN (d.h. SELECTs ausführen) können.

Wie kann ich das bei PGSQL machen? Andere Datenbanksysteme unterstützen das, gibt's bei PGSQL eine Einstellung?

Btw, einen Work-Around suche ich nicht wirklich, der Code sollte/muss so bleiben .. aber ich freu mich auch über work-arounds ...

Danke

Edit: Code formatiert

hm ... ich verstehe nicht ganz was du machst. Du packst die Aktionen in einer Transaktion, weil sie abhängig voneinander sind! Also was soll der Unfug, weiter zu machen, anstatt ein Rollback zu senden und wieder von vorne zu beginnen?

Ansonstens beschäftige dich z.B. mal mit PL/pgSQL, damit kannst du solche komlexe Vorgänge dem SQL-Server ganz überlassen.

Es ist so. Programmiert wird in meinem Projekt nach einem Framework, daher ist die Sache so schlecht zu ändern.

Der Anwendungsfall wo das Problem u.a. Auftritt:

0. BEGIN Transaction
1. Änderung an der Datenbank, welche einen Fehler produziert (Constraint verletzt, Syntax falsch etc.)
2. Lesen (z.B. "SELECT fehlermeldung from meldungen") der zugehörigen selbsterstellten Fehlermeldung aus Datenbank (funktioniert mit MSSQL, Oracle, in PGSQL wird der SELECT nicht mehr ausgeführt).
3. ROLLBACK

Angeblich ist es auch nicht möglich in PGSQL SELECTs auszuführen wenn die Transaktion schon gescheitert ist (hab ich aus anderem Forum).

Einzige Möglichkeit wäre es mit Exceptions seitens der Datenbank zu machen - das geht allerdings nicht mehr bei Syntaxfehlern. Da dies aber bei uns auch auftreten kann (SQL werden dynamisch erzeugt, und durch einen Bug kann da auch mal Schrott rauskommen) ist diese Lösung auch keine wasserdichte.

EDIT: Das Framework ist eigentlich das Problem. Wenn's keinen work-around gibt, dann wird's wohl am besten sein, das auslesen der Fehlermeldung in eine eigene Transaktion zu verschieben.

Für solche Sachen schreibe ich lieber ein stored procedure und lasse die Aktionen direkt in der DB ausführen, die Fehlerbehandlung wird direkt in SP abgefertigt und man bekommt entweder die OK-Meldung oder entprechende Fehlermeldung als Rückgabe. Das ist in meinen Augen am sauberstens.

Ja, wenn man nicht verschiedenste Datenbanksysteme (MSSQL, Oracle, PGSQL und u.U weitere) unterstützen müsste schon.

So aber bräuchte man für jedes DBMS eine eigene stored procedure.

Auch können die Fehlermeldungen Laufzeit-abhängig sein, und spätestens dann ist eine Lösung rein auf der Datenbank nicht mehr machbar.

Ich würde sagen, dann habt ihr euch ja mit Unterstützung mehrere Datenbanksysteme zu leicht gemacht. Das DBMS ist mächtig durch seine besonderen Features, zusätzlich zu den Standard. So wie ihr das macht, nützt ihr das DBMS nur in seine Elementarfunktionen. Die ganzen bequemlichkeiten wie Views, Stored Procedure, User Function, Trigger, Cursor, ... werden nicht angerührt und somit ist das DBMS kaum ausgelastet, und der Client hat dagegen alle Hände voll zu tun. Das ist aber nicht der Sinn der Sache. Das, was man datenbankseitig lösen kann, soll man ja auch dem DBMS überlassen. Wir machen das so: bei der Installation des Programms (WinApp, WebApp) muss der User entscheiden, was er nehmen will (DB2, MS-SQL, Oracle), dann werden entsprechende SP, Views, ... in die DB erzeugt und das Programm kann voll darauf zugreifen. Die Arbeit muss aber einfach gemacht werden, wenn man mehrere DBMS unterstützen will.

Du hast sicher recht das euer Ansatz sicher gerechtfertig ist - bringt aber auch Probleme mit sich.

Unser System (PHP & DB) lauft schon seit Jahren und wurde Ende der 90er begonnen, daher wird das wohl nie abgeändert - und es ist keines Falls ein kleines System.

Aber du kannst dir vorstellen das solch eine "Migration" ohne ein 90% redesign aller Programm-Module und natürlich der Datenbank nicht möglich ist ...

Btw, Views verwendet das System schon (is ja Standard-Syntax), aber stored procedures und triggers (leider) nicht ...

Hmmm, während ich das schreibe kreist das Wort "Machbarkeitsstudie" in meinem Kopf umher, hehe.