Key-Tabelle oder SQL-Sequence?

[KingofKning]

Hallo,


PS für die Ketzter, die ansonsten meine Sympathie genießen: Keyfelder ohne semantischen Inhalt haben den Vorteil, dass bei Änderung Referenzen erhalten bleiben (im Beispiel: Zusammenfasssung zweier Aufträge zu einem)

Was heißt bitteschön semantischer Inhalt? Also ein Keyfeld ohne Inhalt gibt es für mich nicht. Entweder es steht was drin was auch immer oder es ist leer. Leere Felder ergeben aber keinen Sinn für einen Zugriffs-Schlüssel.

Kann ja sein das ich altmodisch bin aber der Formulierung konnt ich nicht wirklich folgen.

Gruß
Gregor

[Allrounder]

@DBender:
Danke für den Fahrplan, so in etwa hatte ich mir das vorgestellt. Das Blocken lass ich erst einmal, aber auf den Rest werde ich mich jetzt stürzen.

@KingofKning:
Ich hatte auch schon die Befürchtung, dass mich niemand versteht, wenn ich Keyfelder ohne Inhalt will. Klar ist eine fortlaufende Nummer auch Inhalt. Mit Inhalt meinte ich verschlüsselte Daten (Auftragsnummer, Jahr, Status, was auch immer...), die immer wieder Probleme machen, wenn sich an den Daten etwas ändert, z.B. Feldlänge.

[BenderD]

@KingofKning: ohne semantischen Inhalt meint: mit Inhalt, ohne Bedeutung (siehe auch unter Semantik in Wikipedia), manchmal nennt man sowas auch Kunstkeys.
@Allrounder: auf meiner Open Source Seite ist da ein Beispiel als SQL Procedure und im MM gabs da auch mal einen Artikel von mir dazu.

Dieter Bender

Was heißt bitteschön semantischer Inhalt? Also ein Keyfeld ohne Inhalt gibt es für mich nicht. Entweder es steht was drin was auch immer oder es ist leer. Leere Felder ergeben aber keinen Sinn für einen Zugriffs-Schlüssel.

Kann ja sein das ich altmodisch bin aber der Formulierung konnt ich nicht wirklich folgen.

Gruß
Gregor

[Allrounder]

Habe ich schon entdeckt. Das ist genau das, was ich brauche, super.

Eine Frage noch:
Die UDF GET_KEY schreibt erst eine neue, um eins erhöhte ID und liest diese im nächsten select-Statement aus und gibt sie zurück.
Gibt die UDF nicht den falschen Wert zurück, wenn ein zweiter Update (Zweiter UDF-Aufruf) erfolgt, bevor der select durchgeführt ist?

[BenderD]

das ganze muss unter Commit laufen (was es bei mir immer tut), dann bleibt der Satz gesperrt bis zum Ende der Transaktion. Wenn du in der Applikation kein Commit hast, kannst du das auch als Service Programm mit embedded SQL bauen, dem Service Programm eine eigene benamte ACTGRP verpassen und in der Function selber commit sagen.
Das schreiben vor dem lesen ist ein einfacher Weg um einen Deadlock durch die Eskalation von Sperren zu vermeiden.

B*D

Habe ich schon entdeckt. Das ist genau das, was ich brauche, super.

Eine Frage noch:
Die UDF GET_KEY schreibt erst eine neue, um eins erhöhte ID und liest diese im nächsten select-Statement aus und gibt sie zurück.
Gibt die UDF nicht den falschen Wert zurück, wenn ein zweiter Update (Zweiter UDF-Aufruf) erfolgt, bevor der select durchgeführt ist?

[Allrounder]

das ganze muss unter Commit laufen (was es bei mir immer tut), dann bleibt der Satz gesperrt bis zum Ende der Transaktion. Wenn du in der Applikation kein Commit hast, kannst du das auch als Service Programm mit embedded SQL bauen, dem Service Programm eine eigene benamte ACTGRP verpassen und in der Function selber commit sagen.
Das schreiben vor dem lesen ist ein einfacher Weg um einen Deadlock durch die Eskalation von Sperren zu vermeiden.

B*D

Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?

[BenderD]

Hallo,

die Variante mit Blockweisem ziehen der Keynummern (immer 50 auf einmal hochaddieren) ist im absoluten Highperformance Test bewährt (bis zu 30 Batchjobs laufen parallel und bringen die Kiste mit allen Prozessoren zum qualmen.
So wie das jetzt erstellt ist, läuft die UDF in der Transaktion des aufrufenden Programmes, sprich: wenn selbiges ohne Commit arbeitet, funzt das nicht (dann bleibt der Satz gesperrt und es kann nur einer und am Ende des Jobs kommt dann ein Rollback.
Bei der Serviceprogramm Variante bewirkt die benamte Activation Group, dass das SRVPGM einen eigenen Commit Scope bekommt und dann macht man in dem SRVPGM den Commit und das drumherumliegende Programm hat da nichts mit zu tun.

D*B

Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?

[Allrounder]

Erst einmal vielen Dank für die umfangreiche Hilfe. Jetzt hab ich's wohl kapiert. *CALLER macht in dem Fall wirklich keinen Sinn. Leider lässt sich mit UPDSRVPGM die Aktivierungsgruppe der UDF nicht ändern: "Programm oder Serviceprogramm verfügt nicht über eine benannte Aktivierungsgruppe." Ich muss wohl ein RPG-Serviceprogramm mit eigener Aktivierungsgruppe erstellen, dass die UDF embedded aufruft, ein Commit absetzt und die ID zurückgibt. Richtig? ... Hoffentlich ;-)

[Allrounder]

Es läuft!!! Habe eine RPG-Prozedur geschrieben, den Code der UDF in die Prozedur kopiert (embedded). Die Prozedur bekommt Tabellenname und Feld und gibt die ID zurück incl. commit. Das ganze ist jetzt eingebunden in einem Service-Programm mit eigener Aktivierungsgruppe. Wenn die letzten Tests noch erfolgreich sind, kann ich zum 2.1. damit in Echtbetrieb gehen. Vielen Dank B*D!