---

Jeg har en database med 2 tabeller LAND og FIRMAAFD.

En primærnøgle i LAND LandId og en fremmednøgle i FIRMAAFD AfdLandId.

Der ER fylde data i tabellerne og nu vil jeg lave relationen, og jeg har
tjekket:

1) at alle værdier i AfdLandId allerede findes i LandId
2) testet for evt. mellemrum før og efter i begge tabeller

Jeg vil gerne have kaskadevis opdatering og sletning og derfor indstillet
til det alligevel får jeg følgende meddelelse, når jeg forsøger at lave
relationen:

'LAND' table saved successfully
'FIRMAAFD' table
- Unable to create relationship 'FK_FIRMAAFD_LAND'.
Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table 'FIRMAAFD'
may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or
ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint. See previous errors.

Jeg har en tilsvarende relation et andet sted i databasen, med de samme
indstillinger - og her er der ingen problem.

Hvad er det jeg overser ?

Mvh KSor

---

"KSsoerensen
>
> Jeg vil gerne have kaskadevis opdatering og sletning

Begrundelse?

> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table 'FIRMAAFD'
> may cause cycles or multiple cascade paths.
http://support.microsoft.com/default.aspx/kb/321843

> Hvad er det jeg overser ?
>
Måske skal dit design kikkes lidt efter i sømmene?

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:498d3a33$0$90276$14726298@news.sunsite.dk...
> "KSsoerensen
>>
>> Jeg vil gerne have kaskadevis opdatering og sletning
>
> Begrundelse?
Kaskasdevis opdatering er da efter min mening en god facilitet, som sparer
mig for kode.

Når jeg sletter et LAND, fordi jeg at forskellige grunde ikke vil hadle med
det pågældende land, så skal alle afdelinger i det pågældende land slette
automatisk.

>
>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table 'FIRMAAFD'
>> may cause cycles or multiple cascade paths.
> http://support.microsoft.com/default.aspx/kb/321843
>
>> Hvad er det jeg overser ?
>>
> Måske skal dit design kikkes lidt efter i sømmene?
>
Måske, men det er vel også derfor jeg starter dette indlæg og regner med at
få nogle konstruktive ideer ... ikk' ?

Tabellen FIRMAAFD er jo også relateret til tabellen FIRMA, hvor nøjagtig den
samme opsætning af relationen mellem FirmaId i tabellen FIRMA og AfdFirmaId
i tabellen FIRMAAFD er brugt UDEN problemer - og argumentationen er her jo,
at hvis jeg opdaterer et FirmaId, skal alle eventuelle afdelingerne "bare
tilrette" AfdFirmaId automatisk - det sparer mig kode. Og kaskadevis
sletning er vel indlysende - sletter jeg firmaet har jeg jo intet at bruge
afdelingerne til - så væk men dem også automatisk.

Er det noget med at en tabel ikke kan indgå i FLERE relationer, hvor dette
kaskadevis opdatering og sletning er sat på ?

Og hvis DET er tilfældet, hvad er så begrundelsen ?

Mvh KSor

---

I got it - tror jeg !

Ses på de 3 tabeller LAND, FIRMAAFD og FIRMA så kan relationen mellem LAND
og FIRMAFD ikke have kaskadevis sletning, da afdelingerne ikke skal slettes,
som følge af at landet slettes, men afdelingerne i det slettede land skal
slettes fordi FIRMAERNE i det pågældende land slettes - derfor skal der være
kaskadevis sletning mellem LAND og FIRMA og så kan der ikke OGSÅ være det
mellem LAND og FIRMAAFD - er det ikke forklaringen omkring sletning ?

Mht kaskadevis opdatering vil jeg da stadig mene, at det skal være muligt på
relationen mellem LAND og FIRMAAFD og også i relationen mellem LAND og
FIRMA (nu sidder jeg ikke lige med db'en så jeg kan prøve)

Mvh


"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
news:498d4735$0$15887$edfadb0f@dtext01.news.tele.dk...
> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
> news:498d3a33$0$90276$14726298@news.sunsite.dk...
>> "KSsoerensen
>>>
>>> Jeg vil gerne have kaskadevis opdatering og sletning
>>
>> Begrundelse?
> Kaskasdevis opdatering er da efter min mening en god facilitet, som sparer
> mig for kode.
>
> Når jeg sletter et LAND, fordi jeg at forskellige grunde ikke vil hadle
> med det pågældende land, så skal alle afdelinger i det pågældende land
> slette automatisk.
>
>>
>>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table
>>> 'FIRMAAFD' may cause cycles or multiple cascade paths.
>> http://support.microsoft.com/default.aspx/kb/321843
>>
>>> Hvad er det jeg overser ?
>>>
>> Måske skal dit design kikkes lidt efter i sømmene?
>>
> Måske, men det er vel også derfor jeg starter dette indlæg og regner med
> at få nogle konstruktive ideer ... ikk' ?
>
> Tabellen FIRMAAFD er jo også relateret til tabellen FIRMA, hvor nøjagtig
> den samme opsætning af relationen mellem FirmaId i tabellen FIRMA og
> AfdFirmaId i tabellen FIRMAAFD er brugt UDEN problemer - og
> argumentationen er her jo, at hvis jeg opdaterer et FirmaId, skal alle
> eventuelle afdelingerne "bare tilrette" AfdFirmaId automatisk - det sparer
> mig kode. Og kaskadevis sletning er vel indlysende - sletter jeg firmaet
> har jeg jo intet at bruge afdelingerne til - så væk men dem også
> automatisk.
>
> Er det noget med at en tabel ikke kan indgå i FLERE relationer, hvor dette
> kaskadevis opdatering og sletning er sat på ?
>
> Og hvis DET er tilfældet, hvad er så begrundelsen ?
>
> Mvh KSor
>
>

---

"KSsoerensen skrev

> Er det noget med at en tabel ikke kan indgå i FLERE relationer, hvor dette
> kaskadevis opdatering og sletning er sat på ?
>
the tree of cascading referential actions must only have one path to a
particular table on the cascading referential actions tree.

Fra firma til land
Fra afdeling til land
Fra firma til afdeling til land
Fra afdeling til firma til land

> Og hvis DET er tilfældet, hvad er så begrundelsen ?
>
Det er by design
Jeg kender ikke begrundelsen for hvorfor MS har designet det på den måde

Normalt vil man bruge triggers (insert/update/delete) til få db til at
overholde dataintegriteten da det giver den største fleksibilitet
Dvs hvis man overhovedet vil lægge regler for dataintegritet på det niveau
og derved sprede forretningslogik til flere forskellige niveauer

Btw mulighed for ændring af fx firmaid er nok ikke den klogeste beslutning
:)
Jeg formoder at firmaid er en primærnøgle der indgår i en del relationer?

I den yderste konsekvens kan man komme på kant med forskellige dele af
lovgivningen
Har du finansposter/bogføring etc i dit system?

- Peter

---

> Btw mulighed for ændring af fx firmaid er nok ikke den klogeste beslutning
> :)
Jow da.

> Jeg formoder at firmaid er en primærnøgle der indgår i en del relationer?
>
Formodningen er rigtig.

> I den yderste konsekvens kan man komme på kant med forskellige dele af
> lovgivningen
Overhovedet ikke !

> Har du finansposter/bogføring etc i dit system?
>
Nej

Mvh KSor

---

"KSsoerensen skrev

>> Btw mulighed for ændring af fx firmaid er nok ikke den klogeste
>> beslutning :)
> Jow da.
>
Hvad er begrundelsen?

>> I den yderste konsekvens kan man komme på kant med forskellige dele af
>> lovgivningen

> Overhovedet ikke !

Kommer an på typen af applikation
Fedter man med bogføringsdata så er der nogen krav i forhold til
lovgivningen der skal overholdes

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:498d59b5$0$90268$14726298@news.sunsite.dk...
> "KSsoerensen skrev
>
>>> Btw mulighed for ændring af fx firmaid er nok ikke den klogeste
>>> beslutning :)
>> Jow da.
>>
> Hvad er begrundelsen?
>
Nu var det overhovedet ikke emnet
og jeg vil gerne have, at man kan ændre FirmaId - derfor.

Alle disse ord var bedre at bruge i forbindelse med forklaring
af det oprindelige problem.

Men jeg vil prøve det af.

Mvh KSor

---

KSsoerensen skrev

> Nu var det overhovedet ikke emnet
> og jeg vil gerne have, at man kan ændre FirmaId - derfor.
>
Det er et frit land

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:498d3a33$0$90276$14726298@news.sunsite.dk...
> "KSsoerensen
>>
>> Jeg vil gerne have kaskadevis opdatering og sletning
>
> Begrundelse?
>
>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table 'FIRMAAFD'
>> may cause cycles or multiple cascade paths.
> http://support.microsoft.com/default.aspx/kb/321843
>
Nu har jeg konstrueret et lille eksempel på SQL-serveren og i MS Access med

LAND
FIRMA
FIRMAAFD

Med relationer mellem LAND-FIRMA (relation A), LAND-FIRMAAFD (B) og
FIRMA-FIRMAAFD (C)

I MS Access kan der være kaskadevis opdatering og sletning på alle
relationerne og det virker efter hensigten.

På SQL-serveren er der den besynderlige "begrænsning" og ovenikøbet "by
design", at relationen (B) IKKE kan - ja, den må overhovedet IKKE være der
uanset hvilken kombination mellem kaskadevis opdaterin/sletning og "Foreign
Key Constraint" der forsøges !

Hvad er det dog for noget skrammel !

Nå, men så må jeg jo til at se på "triggers"

Mvh KSor

---

"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
news:498e8980$0$15880$edfadb0f@dtext01.news.tele.dk...
> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
> news:498d3a33$0$90276$14726298@news.sunsite.dk...
>> "KSsoerensen
>>>
>>> Jeg vil gerne have kaskadevis opdatering og sletning
>>
>> Begrundelse?
>>
>>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table
>>> 'FIRMAAFD' may cause cycles or multiple cascade paths.
>> http://support.microsoft.com/default.aspx/kb/321843
>>
> Nu har jeg konstrueret et lille eksempel på SQL-serveren og i MS Access
> med
>
> LAND
> FIRMA
> FIRMAAFD
>
> Med relationer mellem LAND-FIRMA (relation A), LAND-FIRMAAFD (B) og
> FIRMA-FIRMAAFD (C)
>
> I MS Access kan der være kaskadevis opdatering og sletning på alle
> relationerne og det virker efter hensigten.
>
> På SQL-serveren er der den besynderlige "begrænsning" og ovenikøbet "by
> design", at relationen (B) IKKE kan - ja, den må overhovedet IKKE være der
> uanset hvilken kombination mellem kaskadevis opdaterin/sletning og
> "Foreign Key Constraint" der forsøges !
>
> Hvad er det dog for noget skrammel !
>
> Nå, men så må jeg jo til at se på "triggers"
>
> Mvh KSor
>
Jeg syned de eksempler som findes "derude" er noget uoverskuelige - derfor:

Er der nogen af jer, som har noget kode, som viser en sådan "Trigger" til
opnåelse af den effekt som "kaskadevis sletning og opdatering" kombineret
med Referentiel integritet har i f.eks. MS Access ?

Mvh KSor

---

"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
news:498e8980$0$15880$edfadb0f@dtext01.news.tele.dk...
> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
> news:498d3a33$0$90276$14726298@news.sunsite.dk...
>> "KSsoerensen
>>>
>>> Jeg vil gerne have kaskadevis opdatering og sletning
>>
>> Begrundelse?
>>
>>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table
>>> 'FIRMAAFD' may cause cycles or multiple cascade paths.
>> http://support.microsoft.com/default.aspx/kb/321843
>>
> Nu har jeg konstrueret et lille eksempel på SQL-serveren og i MS Access
> med
>
> LAND
> FIRMA
> FIRMAAFD
>
> Med relationer mellem LAND-FIRMA (relation A), LAND-FIRMAAFD (B) og
> FIRMA-FIRMAAFD (C)
>
> I MS Access kan der være kaskadevis opdatering og sletning på alle
> relationerne og det virker efter hensigten.
>
> På SQL-serveren er der den besynderlige "begrænsning" og ovenikøbet "by
> design", at relationen (B) IKKE kan - ja, den må overhovedet IKKE være der
> uanset hvilken kombination mellem kaskadevis opdaterin/sletning og
> "Foreign Key Constraint" der forsøges !
>
> Hvad er det dog for noget skrammel !
>
> Nå, men så må jeg jo til at se på "triggers"
>
Ups, jeg tog fejl - relationen må godt være der, men den må ikke have
kaskadevis sletning/opdatering - og med YES til "foreign key constraint"
bliver man forhindret i at slette et land, hvis der er afdelinger, som
ligger i dette land.

Men hvad er begrundelsen for at lave denne begrænsning - det fungerer jo
ellers fint i MS Access, som i så mange andre sammenhænge nedgøres til
fordel for SQL-serveren ?

Mvh KSor

---

Det er en design limitation i SQL server som ikke findes i andre RDMBS'er
jeg kender til. Men det er relativt kendt i SQL Server, og jeg har også selv
problemet i et af mine projekter. Mit bedste bud på årsagen er, at det ikke
er veldefineret hvilken rækkefølge UPDATE/DELETE bliver cascadet ned i en
sådan situation. Dvs: Hvis du sletter et LAND, vil din FIRMAAFD så blive
slettet pga relation B eller relation C?, og vil det blive slettet før eller
efter FIRMA?. Det kunne sikkert i en langt ude situation give problemer hvis
man havde komplicerede triggers på hvert table som lavede noget i et af de
andre tables, og at rækkefølgen af dette havde en betydning.

Der er adskillige mulige løsninger:
1) Drop cascading UPDATE/DELETE på en af relationernerne. således at du ikke
har en 'cyklus', men kun en entydig træstruktur.
2) Lav en stored procedure der laver din delete/update, som også sørger for
alle følgevirkninger.
3) Lav en trigger på hoved tabellen som sørger for følgevirkningerne af
update/delete
4) Split den problematiske tabel til 2 selvstændige tabeller
(FIRMAAFD_LANDE, og FIRMAAFD_FIRMA). Dette giver dog kun god mening hvis de
2 sæt data ikke skal dele de samme rækker.


Jesper.

---

> Det er en design limitation i SQL server som ikke findes i andre RDMBS'er
> jeg kender til. Men det er relativt kendt i SQL Server, og jeg har også
> selv problemet i et af mine projekter. Mit bedste bud på årsagen er, at
> det ikke er veldefineret hvilken rækkefølge UPDATE/DELETE bliver cascadet
> ned i en sådan situation. Dvs: Hvis du sletter et LAND, vil din FIRMAAFD
> så blive slettet pga relation B eller relation C?, og vil det blive
> slettet før eller efter FIRMA?. Det kunne sikkert i en langt ude situation
> give problemer hvis man havde komplicerede triggers på hvert table som
> lavede noget i et af de andre tables, og at rækkefølgen af dette havde en
> betydning.

Det har tydeligvis IKKE været en bekymring som MS Access folkene har
haft, idet det virker uden disse lidt "tågede problemer" - "design
limitation" !
>
> Der er adskillige mulige løsninger:

Ja, jeg er mest tilhænger af en løsning, hvor det sker UDEN min indblanden
overhovedet, og så skal det vel være en "trigger" - du siger på
"hovedtabellen"
.... er det i dette tilfælde LAND ?

Og triggeren opgave skal så være ved opdatering af et LAND at foretage
opdatering
i FIRMAAFD.

Resten klares jo af relationen mellem LAND og FIRMA.

Du har ikke et eksempel på en sådan "trigger" ?

Mvh KSor

---

Tja, jeg er enig med dig i at denne begræsning virker lidt overflødig, da
man nok blot kunne dokumentere en veldefineret orden at delete'sne blev
udført i (hvis det ellers er det som er problemet). Men jeg vil nu slet ikke
gå så langt som til at sige at MS Access er bedre fordi den ikke har samme
begræsning. Man har i Access lavet så mange antagelser om normal brug, at
der ikke skal meget til i virkelighedens verden for at din database bliver
corrupted.

Hvis vi blot taget DELETE operationen som eksempel:

Du kan vælge enten metode A:
- Drop helt at have en relation imellem LAND og FIRMAAFD og lav en trigger
således:

CREATE TRIGGER trg_DeleteLand ON LAND
FOR DELETE
AS
BEGIN
DELETE FIRMAAFD FROM FIRMAAFD, deleted
WHERE FIRMAAFD.nLandID=deleted.nLandID
END

Ovennævnte vil ikke virke hvis du har en relation imellem LAND og FIRMAAFD,
fordi den først vil blive udførst *efter* at den refererede række i
hovedtabellen (LAND) forsøges deleted...så inden triggeren overhovedet
kommer i spil vil der være et brudt på 'referential integrity' idet du i
FIRMAAFD nu refererer til en key der ikke længere eksisterer i LAND. Derfor
virker ovenstående kun hvis der ikke er en relation.

Hvis du gerne vil have at der er en LAND-FIRMAAFD relation kan du lave den
(uden cascading updates på den), og så lave følgende trigger:

CREATE TRIGGER trg_DeleteLand ON LAND
INSTEAD OF DELETE
AS
BEGIN
DELETE FIRMAAFD FROM FIRMAAFD, deleted
WHERE FIRMAAFD.nLandID=deleted.nLandID

DELETE LAND FROM LAND, deleted
WHERE LAND.nLandID=deleted.nLandID
END


Her går du ind og siger at *før* den overhovedet prøver at delete rækken i
LAND, så går du ind og sletter de relaterede rækker i FIRMAAFD. Herefter er
du selv ansvarlig for at slette rækken i LAND, hvilket sker i linie 2.

Update med metode A (kræver at der ikke er en relation):

ALTER TRIGGER tgg_UpdateLand ON LAND
FOR UPDATE
AS
BEGIN
IF UPDATE(nLandID)
BEGIN
UPDATE FIRMAAFD
SET FIRMAAFD.nLandID=inserted.nLandID
FROM FIRMAAFD, deleted, inserted
WHERE deleted.nLandID=FIRMAAFD.nLandID
END
END

En update samtidigt med at du har en aktiv relation har jeg faktisk svært
ved at se hvordan man skal gøre. Man bliver givetvist nødt til at disable
relationen først, og aktivere den igen efter kaldet.

Jesper.

---

Thanks - Jesper, det vil jeg prøve

Mvh KSor

"Jesper" <no@spam.com> skrev i meddelelsen
news:4993450d$0$90272$14726298@news.sunsite.dk...
> Tja, jeg er enig med dig i at denne begræsning virker lidt overflødig, da
> man nok blot kunne dokumentere en veldefineret orden at delete'sne blev
> udført i (hvis det ellers er det som er problemet). Men jeg vil nu slet
> ikke gå så langt som til at sige at MS Access er bedre fordi den ikke har
> samme begræsning. Man har i Access lavet så mange antagelser om normal
> brug, at der ikke skal meget til i virkelighedens verden for at din
> database bliver corrupted.
>
> Hvis vi blot taget DELETE operationen som eksempel:
>
> Du kan vælge enten metode A:
> - Drop helt at have en relation imellem LAND og FIRMAAFD og lav en trigger
> således:
>
> CREATE TRIGGER trg_DeleteLand ON LAND
> FOR DELETE
> AS
> BEGIN
> DELETE FIRMAAFD FROM FIRMAAFD, deleted
> WHERE FIRMAAFD.nLandID=deleted.nLandID
> END
>
> Ovennævnte vil ikke virke hvis du har en relation imellem LAND og
> FIRMAAFD, fordi den først vil blive udførst *efter* at den refererede
> række i hovedtabellen (LAND) forsøges deleted...så inden triggeren
> overhovedet kommer i spil vil der være et brudt på 'referential integrity'
> idet du i FIRMAAFD nu refererer til en key der ikke længere eksisterer i
> LAND. Derfor virker ovenstående kun hvis der ikke er en relation.
>
> Hvis du gerne vil have at der er en LAND-FIRMAAFD relation kan du lave den
> (uden cascading updates på den), og så lave følgende trigger:
>
> CREATE TRIGGER trg_DeleteLand ON LAND
> INSTEAD OF DELETE
> AS
> BEGIN
> DELETE FIRMAAFD FROM FIRMAAFD, deleted
> WHERE FIRMAAFD.nLandID=deleted.nLandID
>
> DELETE LAND FROM LAND, deleted
> WHERE LAND.nLandID=deleted.nLandID
> END
>
>
> Her går du ind og siger at *før* den overhovedet prøver at delete rækken i
> LAND, så går du ind og sletter de relaterede rækker i FIRMAAFD. Herefter
> er du selv ansvarlig for at slette rækken i LAND, hvilket sker i linie 2.
>
> Update med metode A (kræver at der ikke er en relation):
>
> ALTER TRIGGER tgg_UpdateLand ON LAND
> FOR UPDATE
> AS
> BEGIN
> IF UPDATE(nLandID)
> BEGIN
> UPDATE FIRMAAFD
> SET FIRMAAFD.nLandID=inserted.nLandID
> FROM FIRMAAFD, deleted, inserted
> WHERE deleted.nLandID=FIRMAAFD.nLandID
> END
> END
>
> En update samtidigt med at du har en aktiv relation har jeg faktisk svært
> ved at se hvordan man skal gøre. Man bliver givetvist nødt til at disable
> relationen først, og aktivere den igen efter kaldet.
>
> Jesper.
>

---

"Jesper" <no@spam.com> skrev i meddelelsen
news:4993450d$0$90272$14726298@news.sunsite.dk...
> Tja, jeg er enig med dig i at denne begræsning virker lidt overflødig, da
> man nok blot kunne dokumentere en veldefineret orden at delete'sne blev
> udført i (hvis det ellers er det som er problemet). Men jeg vil nu slet
> ikke gå så langt som til at sige at MS Access er bedre fordi den ikke har
> samme begræsning. Man har i Access lavet så mange antagelser om normal
> brug, at der ikke skal meget til i virkelighedens verden for at din
> database bliver corrupted.
>
> Hvis vi blot taget DELETE operationen som eksempel:
>
> Du kan vælge enten metode A:
> - Drop helt at have en relation imellem LAND og FIRMAAFD og lav en trigger
> således:
>
> CREATE TRIGGER trg_DeleteLand ON LAND
> FOR DELETE
> AS
> BEGIN
> DELETE FIRMAAFD FROM FIRMAAFD, deleted
> WHERE FIRMAAFD.nLandID=deleted.nLandID
> END
>
> Ovennævnte vil ikke virke hvis du har en relation imellem LAND og
> FIRMAAFD, fordi den først vil blive udførst *efter* at den refererede
> række i hovedtabellen (LAND) forsøges deleted...så inden triggeren
> overhovedet kommer i spil vil der være et brudt på 'referential integrity'
> idet du i FIRMAAFD nu refererer til en key der ikke længere eksisterer i
> LAND. Derfor virker ovenstående kun hvis der ikke er en relation.
>
> Hvis du gerne vil have at der er en LAND-FIRMAAFD relation kan du lave den
> (uden cascading updates på den), og så lave følgende trigger:
>
> CREATE TRIGGER trg_DeleteLand ON LAND
> INSTEAD OF DELETE
> AS
> BEGIN
> DELETE FIRMAAFD FROM FIRMAAFD, deleted
> WHERE FIRMAAFD.nLandID=deleted.nLandID
>
> DELETE LAND FROM LAND, deleted
> WHERE LAND.nLandID=deleted.nLandID
> END
>
>
> Her går du ind og siger at *før* den overhovedet prøver at delete rækken i
> LAND, så går du ind og sletter de relaterede rækker i FIRMAAFD. Herefter
> er du selv ansvarlig for at slette rækken i LAND, hvilket sker i linie 2.
>
> Update med metode A (kræver at der ikke er en relation):
>
> ALTER TRIGGER tgg_UpdateLand ON LAND
> FOR UPDATE
> AS
> BEGIN
> IF UPDATE(nLandID)
> BEGIN
> UPDATE FIRMAAFD
> SET FIRMAAFD.nLandID=inserted.nLandID
> FROM FIRMAAFD, deleted, inserted
> WHERE deleted.nLandID=FIRMAAFD.nLandID
> END
> END
>
> En update samtidigt med at du har en aktiv relation har jeg faktisk svært
> ved at se hvordan man skal gøre. Man bliver givetvist nødt til at disable
> relationen først, og aktivere den igen efter kaldet.
>
> Jesper.
Ja, se det virker faktisk meget ovebevisende pånær det med, at der nu ikke
længere er en relation mellem LAND og FIRMAAFD til at sørge for den
referentielle integritet.

Du nævner, at HVIS relationen er der, skal den muligvis "disables før
kaldet".
1) Hvordan "disables" en relation - jeg kan slette den og lave den igen, men
hvordan "disables" den ???
2) Du skriver godt nok "før" kaldet, men hvis relationen kan "disables" med
noget SQL-kode, kan det så ikke gøres I SELVE trigeren - disable den i
starten an ebable den igen i slutningen af triggeren ?

Mvh
KSor

---

Hvis din constraint hedder FK_FIRMAAFD_LAND :

Disable:
ALTER TABLE FIRMAAFD NOCHECK CONSTRAINT FK_FIRMAAFD_LAND

Re-Enable:
ALTER TABLE FIRMAAFD CHECK CONSTRAINT FK_FIRMAAFD_LAND


Jeg er ikke 100% sikker på om man må fyre den slags kommandoer af i en
trigger, men du kan jo prøve.


Jesper.

---

"Jesper" <no@spam.com> skrev i meddelelsen
news:4998606e$0$90272$14726298@news.sunsite.dk...
> Hvis din constraint hedder FK_FIRMAAFD_LAND :
>
> Disable:
> ALTER TABLE FIRMAAFD NOCHECK CONSTRAINT FK_FIRMAAFD_LAND
>
> Re-Enable:
> ALTER TABLE FIRMAAFD CHECK CONSTRAINT FK_FIRMAAFD_LAND
>
>
> Jeg er ikke 100% sikker på om man må fyre den slags kommandoer af i en
> trigger, men du kan jo prøve.
>
>
> Jesper.
Tak for det - jeg prøver !

Mvh KSor

---

"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i en meddelelse
news:49999a90$0$15872$edfadb0f@dtext01.news.tele.dk...
>
> "Jesper" <no@spam.com> skrev i meddelelsen
> news:4998606e$0$90272$14726298@news.sunsite.dk...
>> Hvis din constraint hedder FK_FIRMAAFD_LAND :
>>
>> Disable:
>> ALTER TABLE FIRMAAFD NOCHECK CONSTRAINT FK_FIRMAAFD_LAND
>>
>> Re-Enable:
>> ALTER TABLE FIRMAAFD CHECK CONSTRAINT FK_FIRMAAFD_LAND
>>
>>
>> Jeg er ikke 100% sikker på om man må fyre den slags kommandoer af i en
>> trigger, men du kan jo prøve.
>>
>>
>> Jesper.
> Tak for det - jeg prøver !
>
Det virker ikke - man kan åbenbart ikke lægge det ind i triggeren

Andre gode ideer ?

Mvh KS

---

KS <keld. skrev:
> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
> news:498d3a33$0$90276$14726298@news.sunsite.dk...
>> "KSsoerensen
>>>
>>> Jeg vil gerne have kaskadevis opdatering og sletning
>>
>> Begrundelse?
>>
>>> Introducing FOREIGN KEY constraint 'FK_FIRMAAFD_LAND' on table
>>> 'FIRMAAFD' may cause cycles or multiple cascade paths.
>> http://support.microsoft.com/default.aspx/kb/321843
>>
> Nu har jeg konstrueret et lille eksempel på SQL-serveren og i MS Access med
>
> LAND
> FIRMA
> FIRMAAFD
>
> Med relationer mellem LAND-FIRMA (relation A), LAND-FIRMAAFD (B) og
> FIRMA-FIRMAAFD (C)
>
> I MS Access kan der være kaskadevis opdatering og sletning på alle
> relationerne og det virker efter hensigten.
>
> På SQL-serveren er der den besynderlige "begrænsning" og ovenikøbet "by
> design", at relationen (B) IKKE kan - ja, den må overhovedet IKKE være
> der uanset hvilken kombination mellem kaskadevis opdaterin/sletning og
> "Foreign Key Constraint" der forsøges !
>
Lidt sent, men:
Relationen B er overflødig, FIRMAAFD skal ikke have feltet LAND, når en
afdeling hænger på et firma, der hænger på et land.

Eller vil du kunne have at et firma i Norge har en afdeling i Sverige?

Og hvis du så ikke vil handle med Norge, men gerne med Sverige, vil du
så handle med afdelingen i Sverige?

Leif

---

KSorskrev
>
> Det virker ikke - man kan åbenbart ikke lægge det ind i triggeren
>
> Andre gode ideer ?
>
Drop dine foreign key constraints og styr det vha update/insert
triggers

eller
Få styr på dit databasedesign

eller
Find et andet rdbms produkt der kan det du vil

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:46d32338-6a79-422d-b725-4059ef21da7b@e10g2000vbe.googlegroups.com...
>>KSorskrev
>>
> >Det virker ikke - man kan åbenbart ikke lægge det ind i triggeren
>>
> >Andre gode ideer ?
>>
>Drop dine foreign key constraints og styr det vha update/insert
triggers

Kan du lave et par eksempler på, hvordan sådan nogle ser ud ?

>eller
>Få styr på dit databasedesign

Designet fejler netop IKKE noget !

>eller
>Find et andet rdbms produkt der kan det du vil

Jeg vil jo nødigt skulle "gå tilbage til" Access.

Mvh KS

---

KS skrev

> Kan du lave et par eksempler på, hvordan sådan nogle ser ud ?

Jow hvis du lægger en del af dit database schema ind her
Hvilken mssql version bruger du?
Hvis det er 2008 må jeg melde pas pt
>
> Designet fejler netop IKKE noget !

Det gør det da?
Du har redundante data i dine tabeller der giver dig nogle
problematikker vedr din implementering på mssql

> Jeg vil jo nødigt skulle "gå tilbage til" Access.
>
Access er /ikke/ blandt de rdbms jeg tænkte på
Access er et dekstop produkt og fungerer med dette udgangspunkt ganske
fornuftigt, selvom jeg har ramt loftet fornylig i forbindelse nogle
datamanipuleringen hvor programmet crashede totalt eller blot tog
timer om at køre en forholdsvis enkel forespørgsel (set med mine mssql
øjne)

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:f9dcb9a4-66e9-490b-84c5-e89b4da83d9c@j38g2000yqa.googlegroups.com...

>Jow hvis du lægger en del af dit database schema ind her
>Hvilken mssql version bruger du?
>Hvis det er 2008 må jeg melde pas pt

Jeg bruger 2005

>>
>> Designet fejler netop IKKE noget !

>Det gør det da?
>Du har redundante data i dine tabeller der giver dig nogle
>problematikker vedr din implementering på mssql

Hvad er det for en redundance du fabler om ?

Problematikkerne opstår fordi MSSQL er lidt mangelfuld på dette
område - se bare på Access, her er det løst !

Mvh KS

---

KS skrev

> >> Designet fejler netop IKKE noget !
> >Det gør det da?
> >Du har redundante data i dine tabeller der giver dig nogle
> >problematikker vedr din implementering på mssql
>
> Hvad er det for en redundance du fabler om ?
>
Du har de samme data i forskellige tabeller

> Problematikkerne opstår fordi MSSQL er lidt mangelfuld på dette
> område - se bare på Access, her er det løst !
>
Der er ganske mange ting Access kan som man ikke ser i et rigtig rdbms
Der er endnu flere ting et rigtigt rdbms kan som ikke Acces ikke evner
og aldrig kommer til at kunne

I den sidste ende er det et spørgsmål om pest eller kolera bruge det
rigtige værktøj rigtigt

Alle seriøse bøger der beskæftiger sig med avanceret Access udvikling
siger samstemmende at man er pisket til at lave db design samt gui
design om den dag man skifter db engine fra fx Access til mssql

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:d275b6b1-cbdf-4edd-b2de-ae66df3ad7dd@a12g2000yqm.googlegroups.com...
KS skrev

>> >> Designet fejler netop IKKE noget !
>> >Det gør det da?
>> >Du har redundante data i dine tabeller der giver dig nogle
>> >problematikker vedr din implementering på mssql
>>
>> Hvad er det for en redundance du fabler om ?
>>
>Du har de samme data i forskellige tabeller

Ja, der er lige præcis den redundance, som er nødvendig for at
kunne lave relationerne.

>> Problematikkerne opstår fordi MSSQL er lidt mangelfuld på dette
>> område - se bare på Access, her er det løst !
>>
>Der er ganske mange ting Access kan som man ikke ser i et rigtig rdbms

Ja, men det burde man overveje at implementere - man kunne spørge MS Access
folkene, hvordan det skal laves og det kommer da nok på et tidspunkt.

>Der er endnu flere ting et rigtigt rdbms kan som ikke Acces ikke evner
>og aldrig kommer til at kunne

Muligt, men det er slet ikke emnet i denne tråd.

Mvh KS

---

KSsoerensen skrev
..
> Ja, der er lige præcis den redundance, som er nødvendig for at
> kunne lave relationerne.

Du skal bruge ikke informationsbærende data for at lave det "korrekt"

Reelt set bør man overveje om det er korrekt udfra et historikmæssigt
synspunkt at slette en type for at oprette en anden/ny type
Ændrer man typen skal det så slå igennem for alle bærere af den gamle type,
eller skal det kun gælde for nogen og ikke for andre - og skal de "andre"
have en tredje type eller måske biobeholde den gamle type
For mig vil det være unaturligt at ændre en type vha cascade update, der er
ikke 100% kontrol med hvad der sker og ud fra et auditmæssigt synspunkt er
det helt hen i hegnet at gøre det du gerne vil

> Ja, men det burde man overveje at implementere - man kunne spørge MS
> Access
> folkene, hvordan det skal laves og det kommer da nok på et tidspunkt.

Der er ganske gode grunde til ikke at gøre det - jvf ovenfor

>>Der er endnu flere ting et rigtigt rdbms kan som ikke Acces ikke evner
>>og aldrig kommer til at kunne
>
> Muligt, men det er slet ikke emnet i denne tråd.
>
Næhh men det er hovedemnet i denne gruppe

Hvordan gik det med det databaseskema så jeg kan sætte noget op mht
triggers?

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:49b28983$0$90271$14726298@news.sunsite.dk...
> KSsoerensen skrev
> .
>> Ja, der er lige præcis den redundance, som er nødvendig for at
>> kunne lave relationerne.
>
> Du skal bruge ikke informationsbærende data for at lave det "korrekt"
>
> Reelt set bør man overveje om det er korrekt udfra et historikmæssigt
> synspunkt at slette en type for at oprette en anden/ny type
> Ændrer man typen skal det så slå igennem for alle bærere af den gamle
> type, eller skal det kun gælde for nogen og ikke for andre - og skal de
> "andre" have en tredje type eller måske biobeholde den gamle type
> For mig vil det være unaturligt at ændre en type vha cascade update, der
> er ikke 100% kontrol med hvad der sker og ud fra et auditmæssigt synspunkt
> er det helt hen i hegnet at gøre det du gerne vil
>
Du er ude i noget dybt akademiske tågesnak om nogle, der ikke skal og
andre der måske skal have rettet type - hvad har det med sagen at gøre ?

I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og alle
AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk og
praktiske
problemer - BORTSET fra, at MSSQL ikke kan implementere det på samme
elegante måde som det kan gøres i MS Access.

>> Ja, men det burde man overveje at implementere - man kunne spørge MS
>> Access
>> folkene, hvordan det skal laves og det kommer da nok på et tidspunkt.
>
> Der er ganske gode grunde til ikke at gøre det - jvf ovenfor
>
Vrøvl og sludder !

>>>Der er endnu flere ting et rigtigt rdbms kan som ikke Acces ikke evner
>>>og aldrig kommer til at kunne
>>
>> Muligt, men det er slet ikke emnet i denne tråd.
>>
> Næhh men det er hovedemnet i denne gruppe
>
> Hvordan gik det med det databaseskema så jeg kan sætte noget op mht
> triggers?
>
Her er tabellerne:

USE [TEST]
GO
/****** Object: Table [dbo].[FIRMA] Script Date: 02/18/2009 20:26:06
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[FIRMA](
[FirmaId] [nvarchar](10) NOT NULL,
[LandId] [nvarchar](10) NOT NULL,
[Beskrivelse] [nvarchar](1000) NULL,
CONSTRAINT [PK_FIRMA] PRIMARY KEY CLUSTERED
(
[FirmaId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
ALTER TABLE [dbo].[FIRMA] WITH CHECK ADD CONSTRAINT [FK_FIRMA_LAND]
FOREIGN KEY([LandId])
REFERENCES [dbo].[LAND] ([LandId])
ON UPDATE CASCADE
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[FIRMA] CHECK CONSTRAINT [FK_FIRMA_LAND]

USE [TEST]
GO
/****** Object: Table [dbo].[FIRMAAFD] Script Date: 02/18/2009 20:27:23
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[FIRMAAFD](
[AfdId] [nvarchar](10) NOT NULL,
[AfdFirmaId] [nvarchar](10) NOT NULL,
[AfdLandId] [nvarchar](10) NOT NULL,
[BEskrivelse] [nvarchar](1000) NULL,
CONSTRAINT [PK_FIRMAAFD] PRIMARY KEY CLUSTERED
(
[AfdId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
ALTER TABLE [dbo].[FIRMAAFD] WITH CHECK ADD CONSTRAINT [FK_FIRMAAFD_FIRMA]
FOREIGN KEY([AfdFirmaId])
REFERENCES [dbo].[FIRMA] ([FirmaId])
ON UPDATE CASCADE
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[FIRMAAFD] CHECK CONSTRAINT [FK_FIRMAAFD_FIRMA]
GO
ALTER TABLE [dbo].[FIRMAAFD] WITH CHECK ADD CONSTRAINT [FK_FIRMAAFD_LAND]
FOREIGN KEY([AfdLandId])
REFERENCES [dbo].[LAND] ([LandId])
GO
ALTER TABLE [dbo].[FIRMAAFD] CHECK CONSTRAINT [FK_FIRMAAFD_LAND]


USE [TEST]
GO
/****** Object: Table [dbo].[LAND] Script Date: 02/18/2009 20:27:45
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[LAND](
[LandId] [nvarchar](10) NOT NULL,
[Beskrivelse] [nvarchar](1000) NULL,
CONSTRAINT [PK_LAND] PRIMARY KEY CLUSTERED
(
[LandId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

og her er en trigger, hvor jeg forsøger af disable/enable relationen mellem
LAND og FIRMAAFD - med det kan ikke lade sig gøre:

USE [TEST]
GO
/****** Object: Trigger [dbo].[tgg_UpdateLand] Script Date: 02/18/2009
20:38:25 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[tgg_UpdateLand] ON [dbo].[LAND]

FOR UPDATE AS
BEGIN

ALTER TABLE FIRMAAFD NOCHECK CONSTRAINT FK_FIRMAAFD_LAND

IF UPDATE(LandID)
BEGIN

UPDATE FIRMAAFD SET FIRMAAFD.AfdLandID=inserted.LandID
FROM FIRMAAFD, deleted, inserted
WHERE deleted.LandID=FIRMAAFD.AfdLandID

END

ALTER TABLE FIRMAAFD CHECK CONSTRAINT FK_FIRMAAFD_LAND

END

Havde det været MS Access kunne man gøre følgende:

1) rette et land og det ville slå igennem på FIRMA og FIRMAAFD
2) slette et land og alle firmaer i dette land ville blive slettet og alle
afdelinger af disse firmaer ville blive slettet også
3) der kan ikke tilføjes en afdeling med et land, som ikke findes i tabellen
land (selvfølgelig skal firmaet også eksistere,
men det er relationen mellem LAND og FIRMAAFD, som er problemet)

Ka' du lave det er det fint.

Mvh KS

---

KSsoerensen skrev

> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og alle
> AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk og
> praktiske problemer

Det vil give mening i min verden hvis man havde stavet "land" forkert oog
kun i det tilfælde

> Her er tabellerne:
>
Tak :)

> 1) rette et land og det ville slå igennem på FIRMA og FIRMAAFD
> 2) slette et land og alle firmaer i dette land ville blive slettet og alle
> afdelinger af disse firmaer ville blive slettet også

I de systemer jeg arbejder med til daglig skulle man så også slette alle
ordrer, fakturaer, kreditnotaer, varebevægelser oma for at beholde
dataintegriteten
Sletter jeg varebevægelser kommer min lagerbeholdning ud af trit med
virkeligheden
Giver det mere mening nu?

> 3) der kan ikke tilføjes en afdeling med et land, som ikke findes i
> tabellen land (selvfølgelig skal firmaet også eksistere,

Alm referentiel integritet, giver mening
I access har jeg typisk oprettet land (hvis den manglede) samtidig med at
firmaet blev oprettet

Skal triggeren kunne det samme?

> men det er relationen mellem LAND og FIRMAAFD, som er problemet)
> Ka' du lave det er det fint.
>
Jeg laver et udkast så må vi se hvordan det spiller sammen med din GUI
Jeg har til hensigt at bruge de nye try/catch blogge der er introduceret i
2005
Hvis det driller må vi tage den derfra :)

Der går lige nogle dage ...

Øh btw bruger du Access som frontend?

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:49b2d0ef$0$90269$14726298@news.sunsite.dk...
> KSsoerensen skrev
>
>> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og
>> alle
>> AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk og
>> praktiske problemer
>
> Det vil give mening i min verden hvis man havde stavet "land" forkert oog
> kun i det tilfælde
>
>> Her er tabellerne:
>>
> Tak :)
>
>> 1) rette et land og det ville slå igennem på FIRMA og FIRMAAFD
>> 2) slette et land og alle firmaer i dette land ville blive slettet og
>> alle afdelinger af disse firmaer ville blive slettet også
>
> I de systemer jeg arbejder med til daglig skulle man så også slette alle
> ordrer, fakturaer, kreditnotaer, varebevægelser oma for at beholde
> dataintegriteten
> Sletter jeg varebevægelser kommer min lagerbeholdning ud af trit med
> virkeligheden
> Giver det mere mening nu?
>
Nu er alt jo ikke "sort eller hvidt" - det skal selvfølgelig i alle tilfælde
nøje
overvejes OM der skal være kaskadevis opdatering/sletning i en given
relation.

Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år siden -
var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
LINIERNE
stadig tilbage efter sletningen - og DET er helt "hen i hegnet" - og der var
masser
af andre tåbelige eksempler - desværre findes det stadig nogle tilfælde i
deres
Dynamics C5.

>> 3) der kan ikke tilføjes en afdeling med et land, som ikke findes i
>> tabellen land (selvfølgelig skal firmaet også eksistere,
>
> Alm referentiel integritet, giver mening
> I access har jeg typisk oprettet land (hvis den manglede) samtidig med at
> firmaet blev oprettet
>
> Skal triggeren kunne det samme?
>
Gerne for eksemplets skyld.

>
> Øh btw bruger du Access som frontend?
>
Jeg bruger noget lavet i C#, men denne DB er blot til test af
problematikken.

Mvh KS

---

KSsoerensen skrev

> Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år
> siden -
> var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
> LINIERNE stadig tilbage efter sletningen

Det burde ikke være muligt slette ordrehovedet i det tilfælde aht
dataintegriteten

Det giver fint mening at linjerne skal slettes før man kan slette hele
ordren da disse måske ikke kan slettes aht andre relaterede data

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
news:49b38001$0$90268$14726298@news.sunsite.dk...
> KSsoerensen skrev
>
>> Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år
>> siden -
>> var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
>> LINIERNE stadig tilbage efter sletningen
>
> Det burde ikke være muligt slette ordrehovedet i det tilfælde aht
> dataintegriteten
>
> Det giver fint mening at linjerne skal slettes før man kan slette hele
> ordren da disse måske ikke kan slettes aht andre relaterede data
>
> - Peter
Ja, men der var ingen test på hverken det ene eller det andet og linierne
lå tilbage uden "hoved" - noget rod !

Mvh KS

---

KS <keld. skrev:
..
>
> Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år
> siden -
> var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
> LINIERNE
> stadig tilbage efter sletningen - og DET er helt "hen i hegnet" - og der
> var masser
> af andre tåbelige eksempler - desværre findes det stadig nogle tilfælde
> i deres
> Dynamics C5.

Man kan sige, at det korrekte i den virkelige verden ville være, at du
overhovedet ikke må kunne slette en faktura. Er fakturaen forkert, skal
der laves en kreditnota.

Eksempeldatabaser er kun eksempler, mange eksempler er uden fejlcheck og
andre ting, der er nødvendige i produktionskode, for ikke at gøre
eksemplet for uoverskueligt.

Leif

---

"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
news:49b35f18$0$56767$edfadb0f@dtext02.news.tele.dk...
> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
> news:49b2d0ef$0$90269$14726298@news.sunsite.dk...
>> KSsoerensen skrev
>>
>>> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og
>>> alle
>>> AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk og
>>> praktiske problemer
>>
>> Det vil give mening i min verden hvis man havde stavet "land" forkert oog
>> kun i det tilfælde
>>
>>> Her er tabellerne:
>>>
>> Tak :)
>>
>>> 1) rette et land og det ville slå igennem på FIRMA og FIRMAAFD
>>> 2) slette et land og alle firmaer i dette land ville blive slettet og
>>> alle afdelinger af disse firmaer ville blive slettet også
>>
>> I de systemer jeg arbejder med til daglig skulle man så også slette alle
>> ordrer, fakturaer, kreditnotaer, varebevægelser oma for at beholde
>> dataintegriteten
>> Sletter jeg varebevægelser kommer min lagerbeholdning ud af trit med
>> virkeligheden
>> Giver det mere mening nu?
>>
> Nu er alt jo ikke "sort eller hvidt" - det skal selvfølgelig i alle
> tilfælde nøje
> overvejes OM der skal være kaskadevis opdatering/sletning i en given
> relation.
>
> Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år
> siden -
> var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
> LINIERNE
> stadig tilbage efter sletningen - og DET er helt "hen i hegnet" - og der
> var masser
> af andre tåbelige eksempler - desværre findes det stadig nogle tilfælde i
> deres
> Dynamics C5.
>
>>> 3) der kan ikke tilføjes en afdeling med et land, som ikke findes i
>>> tabellen land (selvfølgelig skal firmaet også eksistere,
>>
>> Alm referentiel integritet, giver mening
>> I access har jeg typisk oprettet land (hvis den manglede) samtidig med at
>> firmaet blev oprettet
>>
>> Skal triggeren kunne det samme?
>>
> Gerne for eksemplets skyld.
>
>>
Er der nyt i denne sag ?

Mvh KS

---

"KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
news:49cbd581$0$56768$edfadb0f@dtext02.news.tele.dk...
> "KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
> news:49b35f18$0$56767$edfadb0f@dtext02.news.tele.dk...
>> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
>> news:49b2d0ef$0$90269$14726298@news.sunsite.dk...
>>> KSsoerensen skrev
>>>
>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og
>>>> alle
>>>> AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk og
>>>> praktiske problemer
>>>
>>> Det vil give mening i min verden hvis man havde stavet "land" forkert
>>> oog kun i det tilfælde
>>>
>>>> Her er tabellerne:
>>>>
>>> Tak :)
>>>
>>>> 1) rette et land og det ville slå igennem på FIRMA og FIRMAAFD
>>>> 2) slette et land og alle firmaer i dette land ville blive slettet og
>>>> alle afdelinger af disse firmaer ville blive slettet også
>>>
>>> I de systemer jeg arbejder med til daglig skulle man så også slette alle
>>> ordrer, fakturaer, kreditnotaer, varebevægelser oma for at beholde
>>> dataintegriteten
>>> Sletter jeg varebevægelser kommer min lagerbeholdning ud af trit med
>>> virkeligheden
>>> Giver det mere mening nu?
>>>
>> Nu er alt jo ikke "sort eller hvidt" - det skal selvfølgelig i alle
>> tilfælde nøje
>> overvejes OM der skal være kaskadevis opdatering/sletning i en given
>> relation.
>>
>> Men som MS udsendte deres eksempeldatabaser i starter - for 10-15 år
>> siden -
>> var det UDEN - så hvis du sletted et ordrehoved/fakturahoved - ja, så lå
>> LINIERNE
>> stadig tilbage efter sletningen - og DET er helt "hen i hegnet" - og der
>> var masser
>> af andre tåbelige eksempler - desværre findes det stadig nogle tilfælde i
>> deres
>> Dynamics C5.
>>
>>>> 3) der kan ikke tilføjes en afdeling med et land, som ikke findes i
>>>> tabellen land (selvfølgelig skal firmaet også eksistere,
>>>
>>> Alm referentiel integritet, giver mening
>>> I access har jeg typisk oprettet land (hvis den manglede) samtidig med
>>> at firmaet blev oprettet
>>>
>>> Skal triggeren kunne det samme?
>>>
>> Gerne for eksemplets skyld.
>>
>>>
Hvorfor er alle de "skriftkloge" nu blevet så tavse ?

Mvh KS

---

KS <keld. skrev:
>
> "KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
> news:49cbd581$0$56768$edfadb0f@dtext02.news.tele.dk...
>> "KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
>> news:49b35f18$0$56767$edfadb0f@dtext02.news.tele.dk...
>>> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
>>> news:49b2d0ef$0$90269$14726298@news.sunsite.dk...
>>>> KSsoerensen skrev
>>>>
>>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER
>>>>> og alle
>>>>> AFD have rettet fremmednøglen (landet) og det er helt uden
>>>>> teoretisk og praktiske problemer
>>>>

>>>>
> Hvorfor er alle de "skriftkloge" nu blevet så tavse ?
>
> Mvh KS
>

Jeg tror det er fordi du vil gøre noget, man "bare ikke gør".

Leif

---

"Leif Neland" <leif@neland.dk> skrev i meddelelsen
news:49d93303$0$56782$edfadb0f@dtext02.news.tele.dk...
> KS <keld. skrev:
>>
>> "KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
>> news:49cbd581$0$56768$edfadb0f@dtext02.news.tele.dk...
>>> "KS soerensen@os.dk>" <keld.<SLET_DETTE> skrev i meddelelsen
>>> news:49b35f18$0$56767$edfadb0f@dtext02.news.tele.dk...
>>>> "Peter Lykkegaard" <plykkegaard@gmail.com> skrev i meddelelsen
>>>> news:49b2d0ef$0$90269$14726298@news.sunsite.dk...
>>>>> KSsoerensen skrev
>>>>>
>>>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle FIRMAER og
>>>>>> alle
>>>>>> AFD have rettet fremmednøglen (landet) og det er helt uden teoretisk
>>>>>> og praktiske problemer
>>>>>
>
>>>>>
>> Hvorfor er alle de "skriftkloge" nu blevet så tavse ?
>>
>> Mvh KS
>>
>
> Jeg tror det er fordi du vil gøre noget, man "bare ikke gør".
>
> Leif
Hvad er det du tro jeg vil gøre man "bare ikke gør" ?

Mvh KS

---

>>>>>>
>>>>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle
>>>>>>> FIRMAER og alle
>>>>>>> AFD have rettet fremmednøglen (landet) og det er helt uden
>>>>>>> teoretisk og praktiske problemer
>>>>>>
>>
>>>>>>
>>> Hvorfor er alle de "skriftkloge" nu blevet så tavse ?
>>>
>>> Mvh KS
>>>
>>
>> Jeg tror det er fordi du vil gøre noget, man "bare ikke gør".
>>
>> Leif
> Hvad er det du tro jeg vil gøre man "bare ikke gør" ?
>
Jeg har ikke lige det teoretiske udtryk i hovedet, men du vil lade en nøgle
bære en værdi i sig selv.

Du har en tabel med lande, firmaer og afdelinger.
Firmaer og afdelinger er tilknyttet landet.
Lad os antage at du har nøglen "Danmark", og vil ændre det til "Denmark",
det bliver du nødt til at "cascade"re til firma og afdeling.

Den "Korrekte" måde er at lade nøglen kun være en nøgle ind i
lande-tabellen.
Ideelt ved brugeren slet ikke hvad nøglen er, men ser f.ex. kun en pulldown.

Når du vil ændre stavemåden, rettes kun i landetabellen.

Evt kan man lade nøglen være ISO 3-Alpha, "DNK" eller UN/ISO 208, men det er
igen at lægge værdi i en nøgle.

Og, igen, man sletter ikke bare data; det kan ødelægge en masse historik og
konsistens.
Du vil slette et land, fordi du ikke vil handle med det.
Så du må slette firmaer og afdelinger, der hænger på det land.
Så må du slette fakturaer, order og leverancer, der er knyttet til de
firmaer.
Og så stemmer dit lager ikke mere.

Leif

---

"Leif Neland" <leif@neland.dk> skrev i meddelelsen
news:49d9dfbd$0$90269$14726298@news.sunsite.dk...
>>>>>>>
>>>>>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle
>>>>>>>> FIRMAER og alle
>>>>>>>> AFD have rettet fremmednøglen (landet) og det er helt uden
>>>>>>>> teoretisk og praktiske problemer
>>>>>>>
>>>
>>>>>>>
>>>> Hvorfor er alle de "skriftkloge" nu blevet så tavse ?
>>>>
>>>> Mvh KS
>>>>
>>>
>>> Jeg tror det er fordi du vil gøre noget, man "bare ikke gør".
>>>
>>> Leif
>> Hvad er det du tro jeg vil gøre man "bare ikke gør" ?
>>
> Jeg har ikke lige det teoretiske udtryk i hovedet, men du vil lade en
> nøgle bære en værdi i sig selv.
>
> Du har en tabel med lande, firmaer og afdelinger.
> Firmaer og afdelinger er tilknyttet landet.
> Lad os antage at du har nøglen "Danmark", og vil ændre det til "Denmark",
> det bliver du nødt til at "cascade"re til firma og afdeling.
Ja, og det er jo NETOP det man ikke kan på SQL-serveren - lav et tilsvarende
eksempel i MS Access - det kører UDEN problemer !
>
> Den "Korrekte" måde er at lade nøglen kun være en nøgle ind i
> lande-tabellen.
Det er jeg enig med dig i !

> Ideelt ved brugeren slet ikke hvad nøglen er, men ser f.ex. kun en
> pulldown.
Dette er jeg IKKE enig med dig i !
>
> Når du vil ændre stavemåden, rettes kun i landetabellen.
Det er jo præcis det jeg vil opnå !
>
> Evt kan man lade nøglen være ISO 3-Alpha, "DNK" eller UN/ISO 208,
Enig igen !
men det er igen at lægge værdi i en nøgle.
Enig, men uden praktisk betydning!

Resten er nogle forudsætninger, som DU lægger ind, OG som IKKE
er aktuelle i min situation.

> Og, igen, man sletter ikke bare data; det kan ødelægge en masse historik
> og konsistens.
> Du vil slette et land, fordi du ikke vil handle med det.
> Så du må slette firmaer og afdelinger, der hænger på det land.
> Så må du slette fakturaer, order og leverancer, der er knyttet til de
> firmaer.
> Og så stemmer dit lager ikke mere.
>
> Leif
>
>

---

> "Leif Neland" <leif@neland.dk> skrev i meddelelsen
> news:49d9dfbd$0$90269$14726298@news.sunsite.dk...
>>>>>>>>
>>>>>>>>> I det konkrete tilfælde, hvor man retter et LAND skal alle
>>>>>>>>> FIRMAER og alle
>>>>>>>>> AFD have rettet fremmednøglen (landet) og det er helt uden
>>>>>>>>> teoretisk og praktiske problemer
>>>>>>>>
>>>>
>>>>>>>>
>>>>> Hvorfor er alle de "skriftkloge" nu blevet så tavse ?
>>>>>
>>>>> Mvh KS
>>>>>
>>>>
>>>> Jeg tror det er fordi du vil gøre noget, man "bare ikke gør".
>>>>
>>>> Leif
>>> Hvad er det du tro jeg vil gøre man "bare ikke gør" ?
>>>
>> Jeg har ikke lige det teoretiske udtryk i hovedet, men du vil lade en
>> nøgle bære en værdi i sig selv.
>>
>> Du har en tabel med lande, firmaer og afdelinger.
>> Firmaer og afdelinger er tilknyttet landet.
>> Lad os antage at du har nøglen "Danmark", og vil ændre det til
>> "Denmark", det bliver du nødt til at "cascade"re til firma og
>> afdeling.
> Ja, og det er jo NETOP det man ikke kan på SQL-serveren - lav et
> tilsvarende eksempel i MS Access - det kører UDEN problemer !
>>
>> Den "Korrekte" måde er at lade nøglen kun være en nøgle ind i
>> lande-tabellen.
> Det er jeg enig med dig i !
>
Jeg tror grunden til den larmende tavshed er, at ingen ser det som et
problem at man ikke kan lave den forkrøblede cascade-ændring i mssql, fordi
metoden du forsøger at få lavet er grundlæggende forkert.

Lav det rigtigt, og du har ikke problemet.

Eller lav det i applikationslaget, ikke i databasen.

Leif



>> Ideelt ved brugeren slet ikke hvad nøglen er, men ser f.ex. kun en
>> pulldown.
> Dette er jeg IKKE enig med dig i !
>>
>> Når du vil ændre stavemåden, rettes kun i landetabellen.
> Det er jo præcis det jeg vil opnå !

Så har jeg vist misforstået problemet, jeg troede du ville ændre nøglen i
alle tre tabeller.

Leif

---

Leif Neland skrev

> Relationen B er overflødig, FIRMAAFD skal ikke have feltet LAND, når en
> afdeling hænger på et firma, der hænger på et land.

Det er noget vrøvl det forrige firma jeg arbejde i havde afdelinger
verden over
>
> Eller vil du kunne have at et firma i Norge har en afdeling i Sverige?

Det er ikke usandsynligt

- Peter