Interbase genererer svært uvennlige navn for begrensninger. Dette er et skript som vil gjøre det generere mer vennlig seg.
/*
FORSLAG om hvordan du kontrollerer navn på indekser som UNDERLY primær- og fremmednøkler
noen kommentarer om dette skriptet : ================================
Interbase (her: IB5.x på Wintel) genererer en indeks hver gang du erklære en primær eller fremmednøkkel for en tabell. Den pk eller fk er en begrensning som kan gis et navn, men det genererte indeksen alltid standard til et navn som "RDB $ PRIMARYnn" henholdsvis "RDB $ FOREIGNnn" der nn er et tall som er gitt av et system generator. Definere et annet navn ikke tilbys av DDL hva er egentlig beklagelig.
Pk /fk begrensninger er lagret i RDB $ RELATION_CONSTRAINTS system bord. I RDB $ begrensnings kolonne finner du navnet på begrensningen på fk /pk og RDB $ INDEX_NAME kolonne lagrer navnet på indeksen IB genererer for deg. Data om indeksene er lagret i RDB $ indekser og RDB $ INDEX_SEGMENTS tabeller. Når ingen rekord i RDB $ RELATION_CONSTRAINTS refererer en indeks kan du oppdatere denne indeksen poster i RDB $ indekser og RDB $ INDEX_SEGMENTS og selv endre en indeks navn på denne måten (f.eks for brukeren erklært indekser). For indekser som er brukt for en forbindelse begrensning dette forhindres av et system utløser. På den annen side oppdatere RDB $ RELATION_CONSTRAINTS synes å være generelt forbudt.
Å bryte disse grensene Jeg erklærer en ekstra før innsetting avtrekkeren på RDB $ RELATION_CONSTRAINTS der jeg endre standard indeksen navn og endre den til en sammensetning av prefikset " IDX_ "og navnet på den underliggende ref. begrensningen. Opprinnelig navn og byttet navn lagres midlertidig i tabellen "hacked_indexnames". Utløseren er sparket når f.eks en tabell er opprettet som inneholder en primær eller fremmednøkkelbegrensning. Etter dette har skjedd RDB $ RELATION_CONSTRAINTS bord har en ny rekord med min "IDX_xxxx" navn i RDB $ INDEX_NAME kolonne. (Merk at navnet på begrensningen ikke må være lengre enn 31-4 = 27 tegn!) I dette øyeblikket er dette en inkonsekvent situasjon, fordi indeksen likevel har vært lagret under det standardnavnet i RDB $ indekser og RDB $ INDEX_SEGMENTS og så ny rekord i RDB $ RELATION_CONSTRAINTS peker på en indeks som ikke eksisterer. Likevel denne situasjonen gjør at jeg kan endre de nye rekorder i RDB $ indekser og RDB $ INDEX_SEGMENTS, hva som er gjort av mine lagret prosedyre "apply_indexnames". Du må utføre denne prosedyren hver gang etter at du har opprettet en tabell eller laget relasjons begrensninger på en annen måte. COMMIT før en etter gjennomføring av "apply_indexnames" synes å være nødvendig fordi Interbase kernel (gjør slikt eksisterer?) Ser ut til å ha sin egen oppfatning til systemtabeller.
Manus under demon denne "hack".
Run det og prøv for eksempel "SET PLAN;" og "SELECT * FROM en ORDER BY a1;" og du får
PLAN (A ORDER IDX_PK_A)
heller enn "PLAN (A ORDER RDB $ PRIMARY1)"
Du kan bruke hacket indeksnavn i Plan klausuler. Validere database rapporter ingen feil og hacket indeksnavn selv overleve en g'backup /resorte. Uansett, selvfølgelig jeg IKKE hevder dette er en sikker måte å gå heller ikke jeg anbefale å bruke det. Dette er bare et eksempel som kommer av hva du kan gjøre på deg. Føl deg fri til å bruke den på en "AS_IS" basis
Fyll er Velkommen Karsten Strobel AIT GmbH - Augsburg Tyskland (03-AUG-1998)
e-post:.. [email protected]
28-OCT-1999: Testet med IB5.6 (Wintel), fungerer fortsatt fine product: * /
CREATE DATABASE "C: \\ TEMP \\ TEST.GDB" USER "SYSDBA" PASSORD "masterkey";
CREATE TABLE hacked_indexnames (OLD_NAME VARCHAR (31), NEW_NAME VARCHAR (31));
SET SIKT ^;
CREATE TRIGGER rel_constr_bi FOR RDB $ RELATION_CONSTRAINTS FØR SETT AS deklarerer variabelen new_idx_name VARCHAR (31); BEGIN IF (NEW.RDB $ INDEX_NAME ER IKKE NULL OG NEW.RDB $ CONSTRAINT_TYPE IN ( "PRIMARY KEY", "FOREIGN KEY")), og start new_idx_name = "IDX_" || NEW.RDB $ begrensnings; /* Dette vil mislykkes hvis lenger enn 31 tegn !!! * /INSERT INTO hacked_indexnames VERDIER (NEW.RDB $ INDEX_NAME,: new_idx_name); NEW.RDB $ INDEX_NAME = new_idx_name; END END ^
CREATE PROSEDYRE apply_indexnames AS deklarerer variabelen old_idx_name VARCHAR (31); Deklarerer variabelen new_idx_name VARCHAR (31); BEGIN FOR SELECT OLD_NAME, NEW_NAME Fra hacked_indexnames TIL: old_idx_name,: new_idx_name DO BEGIN UPDATE RDB $ INDEX_SEGMENTS SET RDB $ INDEX_NAME =: new_idx_name HVOR RDB $ INDEX_NAME =: old_idx_name; OPPDATERING RDB $ indeksene RDB $ fremmed =: new_idx_name HVOR RDB $ fremmed =: old_idx_name; OPPDATERING RDB $ indeksene RDB $ INDEX_NAME =: new_idx_name HVOR RDB $ INDEX_NAME =: old_idx_name; END DELETE FROM hacked_indexnames; END ^
SET SIKT; ^
CREATE TABLE en (a1 INTEGER NOT NULL CONSTRAINT pk_a PRIMARY KEY, a2 INTEGER);
COMMIT; EXECUTE PROSEDYRE apply_indexnames; COMMIT;
CREATE TABLE b (b1 INTEGER NOT NULL CONSTRAINT pk_b PRIMARY KEY, referanser b2 INTEGER CONSTRAINT fk_b2_a en (a1));
COMMIT; EXECUTE PROSEDYRE apply_indexnames; COMMIT;
ALTER TRIGGER rel_constr_bi inaktive,
COMMIT;