[IB/FB] Wo und wie in DB gültige Konstante setzen ?

[Hansa]

Hi,

an einigen Stellen brauche ich Konstanten, die DB-relevant sind. Es genügt also nicht, die nur im Programm zu setzen/auszulesen. Die DB muß sie eventuell in einer SP usw. verwenden. Sie muß also davon Kenntnis haben. Praktikabel wäre z.B. eine INI, die die Konstanten enthält. Ändere ich einen Wert, dann gilt ab dann eben der. Aber wie kann die DB diese lesen und verarbeiten ? Any Ideas ? UDF nötig oder gehts einfacher ?

[mkinzler]

Du könntest diese auch in der datenbank selber ablegen. Z.B. in einer Systabelle oder einem Generator

[Lemmy]

Hi Hansa,

zu was ne INI nehmen wenn Du ne Datenbank hast? Du kannst doch beliebige Tabellen erstellen mit beliebigen Attributen....
Das über ne UDF zu lösen wäre mir zu heiß: Ein Zugriff auf eine (INI-)Datei und das auch noch mehrfach auf dem Server....???? Schreib Dein Zeug in eine oder mehrere Tabellen und gut ist....

Lemmy

[Hansa]

Ja klar, aber die Werte werden oft gebraucht. Ich will ja vermeiden, dauernd etwas, was nicht geändert wird, neu zu lesen und das womöglich noch zu verwursteln, äh verjoinen.

Z.B. brauche ich 99 Haupt-Warengruppen. Einem reicht das nicht und er will 999. Gut lege den Wert eben in Tabelle. Dieselbe Tabelle enthält jetzt noch 5 stellige Gruppen, als Feingliederung, sagen wir als Untergruppe. Es besteht also ein Unterschied bezüglich der Nummern. Überschneiden dürfen die sich nicht ! Jetzt will einer eine Liste aller Artikel seiner Hauptgruppen.

ich mache hierzu folgendes :

SQL-Code:

SELECT * FROM ART JOIN WG ON (blabla) WHERE NR <= 99

Wegen der 99 müßte dann noch ein JOIN da rein, obwohl der Wert klar ist. Es könnte aber auch 999 sein. Die "Systemtabelle" ist eigentlich überflüssig, sofern der Wert aus einer INI kommt. Soweit meine Überlegungen. Wie mkinzler vorschlägt, einen Generator dazu zu mißbrauchen, das könnte vielleicht gehen. :gruebel: Ich will halt nicht überall extra einen konstanten Wert aus einer Tabelle lesen und eben statt 2 Tabellen 3 benutzen müssen. Bleibt die eigene "Systemtabelle" außen vor, dann gehts programmseitig auch nur mit Parametern, die immer denselben Wert haben. Dann schleppe ich die eben unnötig mit und bin auch nicht weiter.

[TBx]

Hallo Hansa!

Wenn ich mich recht erinnere, unterstützt der Firebird ab der Version 2.0 DB-weite Variablen. Müßtest Du mal bei firebirdsql.org nachlesen.

Für Integerwerte würde ich einen Generator mißbrauchen (wenn globale Variable noch nicht unterstützt), da dieser nicht von Transaktionen abhängig ist. Eine Änderung des Generators ist sofort für jeden in jeder noch offenen oder auch neu geöffneten Transsaktion sichtbar.

Gruß

onlinekater

[Hansa]

FB 2.0 ist genau das, was ich jetzt gerade lese. Habe letzte Woche umgestellt. Da war doch was. :mrgreen:

Jup, es sind die Kontext-Variablen und dadurch kommen UDF ins Spiel. Dies bedeutet Arbeit, aber jetzt nicht mehr. 8) Wer weiß, was genau zu tun ist solls einfach sagen.

[mkinzler]

Was haben Kontextvariablen mit UDF zu tun?

Ab FB2.0 kann man benutzerdefinierte Kontextvariablen für die verschiedene Gültigkeitsdauern angeben ( Sitzung, Transaktion.
Die Variablen können mit der Funktionen RDB$SET_CONTEXT und RDB$GET_CONTEXT gesetzt und wieder ausgelesen werden.

SQL-Code:

RDB$SET_CONTEXT ( '<Namensraum'>, '<contextvar>');

Die möglichen Namensräume wären SYSTEM, USER_SESSION, USER_TRANSAKTION.

[hoika]

Hallo,

ich denke, du gehst falsch an die Sache ran.
Ob du 99 oder 999 Warengruppen hast, ist doch Wurscht ;)
Definiere eine Tabelle Warengruppe

ID Integer
Number Integer
Name String

ID ist der künstliche Primärschlüssel.

Und dann lass den Anwender doch seine 99 oder 9999 oder 99999
Warengruppen eintragen.
Du könntest natürlich in der Datenbank über Trigger
verhindern, dass mehr als 99 oder 999 Warengruppen eingetragen werden können.

Willst du das ?


Heiko