"" bei SQL bzw. Interbase

[Lemmy]

Hi Hansa,

Zitat von Hansa:

@Admin : Bei mir gibts kein "BBcode immer aktivieren"

Vielleicht liegt es aber auch an meiner IBconsole (i.e. IBexpert) aus Flensburg.

Code:

CREATE GENERATOR GEN_KG8_ID;
SET GENERATOR GEN_KG8_ID TO 70


CREATE TRIGGER KG8_BI0 FOR KG8
ACTIVE BEFORE INSERT POSITION 0
AS
begin
  new.ID = GEN_ID (gen_kg8_id,1);
end

Hier sieht man schön (alles Original), daß bei dem Generator alles groß und beim Trigger alles kleingeschrieben ist. Demnach würde eventuell CaseSensitive zuschlagen, warum auch immer. Holger Klemt (IBexpert) hat mir noch keine Antwort hierauf gegeben. Die Vermutung (Casesensitive / -insensitive) hatte ich nämlich auch.

Du mischt bei diesen beiden Statements erst mal nix. Die Unterscheidung ob Casesensitive gearbeitet wird (zumindest bei der IBConsole) hängt einzig von den " ab. Ohne fährst Du immer besser. Zwar fügt IB diese bei der Extraktion der Metadaten immer an, aber da konnte ich bisher keine Fehler feststellen.

Grüße
Lemmy

[Hansa]

Hallo Lemmy,

also es liegt meiner Ansicht nach wirklich an IBexpert. Vielleicht ist es in der IBconsole aber genauso. Habe jetzt die Generator- und Triggernamen alle groß geschrieben.

Um dies zu tun, mußte ich die Tabelle kunde8 aber leider löschen, zumindest auf die Schnelle ging es nicht anders.

Der Fehler in dem einen Trigger (Fehlermeldung : GEN_kunde8_ID exist. nicht) ist jetzt auch weg. Der Generator heißt jetzt GEN_KUNDE8_ID, sonst ist nichts verändert.

Meine ursprüngliche Frage, was es mit den " auf sich hat, ist also fast geklärt.

Zitat:

IB 6.0.2 (meines Wissens nach alle 6.x) arbeiten grundsätzlich CaseINsensitive, d.h. Groß-Kleinschreibung kann gemischt werden. Wenn man allerdings Tabellennamen,Triggers,... in " setzt arbeitet man Casesensitive und zusätzlich kann man alles mögliche als Tabellennamen benutzen

Dies würde aber bedeuten, daß es doch nicht CaseINsensitiv ist, sondern es kommt sehr wohl auf die Schreibweise an. Habe sogar die Vermutung, daß sobald ein einziges Zeichen eines Identifiers klein geschrieben wird, das ganze Wort in " erzeugt wird und es dadurch CaseSensitiv wird.

Gruß
Hansa

[Hansa]

Hi,

mir ist gerade noch eingefallen, in Delphi muß man dann aber auch aufpassen mit FieldByName usw. Dieser ganze Mist ist Unix zu verdanken.

Gruß
Hansa

[Hansa]

Oh je,

Zitat:

This operation is not defined for system tables.
unsuccessful metadata update.
MODIFY RDB$FIELDS failed.
action cancelled by trigger (1) to preserve data integrity.
Cannot update index segment used by an Integrity Constraint.

Das hier kam jetzt, als ich die Domain IDtyp in IDTYP umbenennen wollte.

Dann habe ich noch einen Generator, den ich droppen wollte :

IBE$VERSION_HISTORY_ID_GEN

Dieser wurde von mir beim Ausprobieren irgendwann einmal erzeugt. Was er macht weiß ich nicht genau. Er lässt sich aber nicht mehr löschen. Irgendwas wie "not defined for system tables". Fazit : Lemmy hat Recht ! Man kann sich leicht das Genick brechen. Vor allem dann, wenn man es so macht, wie es richtig wäre, aber doch nicht so ist.

Gruß
Hansa

[Gast]

Hallo Hansa, 8)

mit Domänen habe ich bis jetzt nicht so viel experimentiert, da ich solche Konstrukte (wg. Kompatibilität mit anderen SQL Datenbanken) maide.

Nun bin ich aber neugierig geworden ... und frage Dich... wie sieht die SQL- Definition von der besagten Domäne... da die Benutzung von selbst definierten Domänen sollte zumindest mit irgendwelchem logischem Bedarf begründet werden... es sei dem Du experimentierst gerade...

Wie auch immer... meine SQL-Scripts halte ich immer in Großbuchstaben, da NICHT nur InterBase (wie ich hier sehe) hat manchmal damit Probleme.

Vor ein paar Monaten musste ich alle Query-Scripts einer Anwendung, die auch unter ORACLE lief , auf Großschreibung umzustellen..., da manche Oracle-Versionen es nicht gepackt haben....

Aus diesem Grund empfiehlt sich auch für Dich sämtliche Scripts in Großbuchstaben zu halten.

Bin mir nicht sicher, aber vielleicht Deine selbstdefinierte Domäne lässt sich deswegen nicht umbenennen bzw. löschen da diese in Deinen Tabellen für Feld-Definitionen verwendet wird.

Gruß

Paul Jr.

[Hansa]

Hallo PaulJr,

Code:

CREATE DOMAIN "IDtyp" AS
INTEGER NOT NULL


CREATE DOMAIN STR25 AS
CHAR(25) CHARACTER SET ISO8859_1
COLLATE ISO8859_1

Um in einem größeren Programm Fehler zu vermeiden, legt man sich ja selber Typen an. Brauche z.B. öfters string [25]. Deshalb die Domain STR25.

In Interbase kommt noch hinzu (siehe oben), daß nicht nur die Länge des strings, sondern auch noch die Sortierreihenfolge, der Character Set ,NOT NULL usw. in der Domain hinterlegt ist. Hätte ich keine Domain, müßte ich bei jedem String [25] das alles von Hand machen, inklusive Fehlersuche.

Sollten die Felder für irgend jemand länger werden müssen, so kann ich dann mit ALTER DOMAIN dies entsprechend anpassen, nur kürzer werden dürfen sie nicht.

Hinzu kommt noch, daß Interbase ohne Domain für jedes Feld, also auch für die ID automatisch eine Domain anlegt. Und zwar für JEDE ID. Was Speicherplatz braucht und nichts bringt. Dafür die Domain IDtyp.

Gruß
Hansa

[Hansa]

Hi,

Habe jetzt die DB gelöscht und lege sie neu an. Alles in GROßBUCHSTABEN.
Sieht besser aus als vorher. Dafür fehlt mir jetzt der BEFORE UPDATE Trigger. Hat jemand ein Beispiel ? Wie sage ich immer : Datensicherung nicht vergessen !!

Gruß
Hansa

[Gast]

Hallo Hansa, 8)

(...)
Um in einem größeren Programm Fehler zu vermeiden, legt man sich ja selber Typen an. Brauche z.B. öfters string [25]. Deshalb die Domain STR25.
(...)

Zwar weiß ich nicht welche Programm Fehler Du in diesem Zusammenhang meinst... sind jedoch Deine weitere Ausführungen (aus Sicht Deiner Bedürfnisse) zu diesem Thema OK.

Vielleicht sollte man an dieser Stelle einen Begriff erwähnen der hier am besten passen würde:

Domänenintegrität

dessen Einsatzbereich reicht viel, viel weiter....als der hier vorgetragenen... und oft sind diese was der Einsatz betrifft mit Trigger vergleichbar bzw. Austauschbar...!

Nun warum habe ich Dir eigentlich diese Frage gestellt?

Da ich hier folgendes gesehen habe:

Code:

    ID         "IDtyp" NOT NULL,

was gewiss nur ein Versehen sein dürfte, da:

Code:

    ID IDTYP,

schon reichen müsste…

Sonnst... weiter so...

Gruß

Paul Jr.

Code:

CREATE TRIGGER ANSCHRIFT_UPDATE FOR ANSCHRIFT BEFORE UPDATE POSITION 0 AS
BEGIN
  NEW.AENDDATUM='NOW';
  IF (NEW.KURZNAME='') THEN
    NEW.KURZNAME=NULL;
END^

[Lemmy]

Zitat von Paul Jr.:

sind jedoch Deine weitere Ausführungen (aus Sicht Deiner Bedürfnisse) zu diesem Thema OK.

Hi PaulJR,

noch was zum Thema Domains von mir: Interbase hat die unangenehme Eigenschaft für jeden verwendeten Datentyp (z.B in einer Tabelle(Attribute), StoredProcedure (Übergabeparameter)), eine automatisch erzeugte Domain anzulegen, außer das Attribut wurde mit einer DOmain erzeugt. Das hat 2 Nachteile: 1. die bekommen automatisch erzeuge Namen, die nix aussagen, 2. Selbst bei einer kleinen Datenbank bekommst Du sehr schnell sehr viele Domains zusammen. Das macht ein Backup/Restore Sau langsam und die Datenbank wird unnötig aufgebläht. Leider kann man bei StoredProcs noch keine Domains benutzen...

Grüße
Lemmy

[Gast]

Hallo Lemmy, 8)

natürlich sind solche Argumente (wie die Deine) zu beachten...

So oder so... der Einsatz von Domänen dürfte schon etwas mehr sein als NUR Platz... bzw.... Geschwindigkeit Gewinn bei RESTERE/BECKUP....Funktionen...da... sollte man (laut diesem Prinzip) bei 100 Tabellen einer Anwendung NUR Domänen (Selbstdefinierten Datentypen) verwendet...wäre dann das Perfekte SQL-Spript-Chaos entstanden...
Bis heute habe ich das (zum Glück) noch nirgendwo erlebt...

Ich weiß aber schon wie Du das meinst (gewiss als einer von vielen Argumenten dafür...)... nun es gibt’s auch welche die dagegen sprechen dürften...usw...

Na ja... ein ID Feld als Domäne sehe ich Wahrhaftig zum ersten mall... ist aber nicht weiter schlimm... so lange man noch zu Hause programmiert...

Gruß

Paul Jr.