PL/SQL dynamisch unterschiedlich viele Datensätze?

[Horst]

Hallo zusammen,

wir sollen eine Datenanwendung programmieren die Mehrbenutzerfähig ist.
Wir dürfen dabei keine fertige Semaphorentechnik des DBMS benutzen.
Bisher habe ich es so gemacht, dass wenn man über das Frontend
einen Datensatz löschen möchte, wurde der zu löschende Datensatz
komplett mitübergeben und geprüft, ob sich dieser in der Zwischenzeit
geändert hat.
Das funktioniert auch. Jetzt habe ich aber das Problem, dass man aus
einer Tabelle alle Datensätze löschen möchte die z.B. die ID = 1 haben.
Das heisst, es gibt zwischen 0 und x Datensätzen die ich an die Prozedur
übergeben muß, um zu prüfen ob sich einer der Datensätze geändert hat.

Kann ich die Anzahl der zu übergebenen Parameter dynamisch angeben?
Normalerweise würde ich einfach einen String übergeben und den in ein
mehrdimensionales Array splitten, aber das geht bei PL/SQL nicht, oder?!

Viele Grüße
Horst

[Lude]

Hi,

Das funktioniert auch. Jetzt habe ich aber das Problem, dass man aus
einer Tabelle alle Datensätze löschen möchte die z.B. die ID = 1 haben.
Das heisst, es gibt zwischen 0 und x Datensätzen die ich an die Prozedur
übergeben muß, um zu prüfen ob sich einer der Datensätze geändert hat.

Kann ich die Anzahl der zu übergebenen Parameter dynamisch angeben?
Normalerweise würde ich einfach einen String übergeben und den in ein
mehrdimensionales Array splitten, aber das geht bei PL/SQL nicht, oder?!

also mit TSQL geht sowas nicht. - Aber das ist ja auch von Microsoft.
Aber im Ernst: Wo ist das Problem?

Du uebergibst einer Routine das Loeschkriterium und diese prueft, ob sich der Datensatz geaendert hat und so weiter...
Der Ansatz der genannten Routine eine variable Parameteranzahl mitzgeben wird moeglicherweise nicht erfolgreich sein.

Gruss,
Lude

[horst]

Hi Lude

Du uebergibst einer Routine das Loeschkriterium und diese prueft, ob sich der Datensatz geaendert hat und so weiter...

Wie soll die denn wissen ob sich was geändert hat???
Bis her gebe ich ihr die alten Parameter mit... aber das geht ja in diesem fall nicht

gruss
horst

[Lude]

Hi,

Du uebergibst einer Routine das Loeschkriterium und diese prueft, ob sich der Datensatz geaendert hat und so weiter...

Wie soll die denn wissen ob sich was geändert hat???
Bis her gebe ich ihr die alten Parameter mit... aber das geht ja in diesem fall nicht

ich wuerde, dass was Du ins Auge fasst, als Design-Missgriff bezeichnen, da Dein Vorhaben _moeglicherweise_ nicht von Deinem SQL-Dialekt uneterstuetzt wird.

Die "Loesch-Routine" muss ein Loeschkriterium erhalten und dann selbst pruefen koennen, ob der Datensatz geaendert worden ist (dann kein Loeschen vermute ich mal).

Kannst Du es nicht im o.g. Sinne formulieren? Warum nicht?

Gruss,
Lude

[horst]

Hallo,

also nochmal... in diesem speziellen Fall geht es um das Löschen
eines Zug-Fahrplans. Da dieser x Stationen haben kann, müsste
ich beim Löschen x Stationen übergeben und x mal prüfen ob sich die
Daten geändert haben.
Das x-mal prüfen ist kein Problem, aber x*mal den Datensatz (Zug-Id, Gleis-ID, Abfahrtszeit, Hält-Hältnicht) übergeben, das geht so nicht,
weil es ja für jeden Zug unterschiedlich viele Stationen geben kann.

.....

[Lude]

Hi,

hab's leider immer noch nicht verstanden.
Aber dennoch ein spekulativer Tipp: Du koenntest die zu loeschenden Datensaetze in eine temporaere Tabelle schreiben, die wiederum von der Loesch-Routine ausgwertet wird. Mal an den Einsatz von Cursorn gedacht?

Gruss,
Lude

[horst]

hi,

hab's leider immer noch nicht verstanden.
Aber dennoch ein spekulativer Tipp: Du koenntest die zu loeschenden Datensaetze in eine temporaere Tabelle schreiben, die wiederum von der Loesch-Routine ausgwertet wird. Mal an den Einsatz von Cursorn gedacht?

Wenn ich die Select-Prozedur-Anweisung von Java aus an die db schicke,
dann macht es danach gleich ein Commit, die temporären Daten sind
also nicht mehr sichtbar. Irgendwie gibt es da was wie "setAutoCommit
(off)".. habs aber nicht hinbekommen, kennst Du Dich damit aus?
Ansonsten ist das System halt nicht 100% mehrbenutzerfähig

gruss
horst

[Lude]

Hi,

m.E. solltest Du die von Dir beschriebene "Loesch"-Logik "nahe an der DB" unterbringen. Also eine serverseitig "liegende" SP (gespeicherte Prozedur) fuer den Job. (Ausserdem solltest Du die Frontends keine SQL-Statements zusammenbasteln lassen, sondern nur geeignet parametrisierte SP-Aufrufe ausfuehren lassen.)

Wenn ich die Select-Prozedur-Anweisung von Java aus an die db schicke,
dann macht es danach gleich ein Commit, die temporären Daten sind
also nicht mehr sichtbar. Irgendwie gibt es da was wie "setAutoCommit
(off)".. habs aber nicht hinbekommen, kennst Du Dich damit aus?
Ansonsten ist das System halt nicht 100% mehrbenutzerfähig

keine ausreichenden Java-Kenntnisse vorhanden

Gruss,
Lude