![]() |
Hi Hansa,
Zitat:
Grüße Lemmy |
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:
Gruß 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. :twisted: Gruß Hansa |
Oh je,
Zitat:
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. :mrgreen: Vor allem dann, wenn man es so macht, wie es richtig wäre, aber doch nicht so ist. Gruß Hansa :freak: |
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 :mrgreen: ... 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. |
Hallo PaulJr,
Code:
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.
CREATE DOMAIN "IDtyp" AS
INTEGER NOT NULL CREATE DOMAIN STR25 AS CHAR(25) CHARACTER SET ISO8859_1 COLLATE ISO8859_1 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 :witch: |
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 !! :oops: Gruß Hansa |
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:
was gewiss nur ein Versehen sein dürfte, da:
ID "IDtyp" NOT NULL,
Code:
schon reichen müsste…
ID IDTYP,
Sonnst... weiter so... :D 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^ |
Zitat:
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 |
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... :mrgreen: Gruß Paul Jr. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:08 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz