---

Hej NG.

Sidder med VS2005 og MS SQL 2005 Express.

Har to tabeller: A og B.

Tabel A og tabel B har begge *samme* primærnøgle (et enkelt felt).

Jeg ønsker at definere en relation imellem A og B, som som kræver, at hvis
en række findes i tabel B, så skal B's primærnøgle findes i tabel A (altså
en ganske almindelig foreign key relation).

Det kan jeg også fint, men desværre kræver relationen så også, at det
omvendte er tilfældet, og det ønsker jeg absolut ikke!

Det kan da ikke passe, at man ikke kan lave en relation, som kun checker den
ene vej????

- Martin

---

Martin Christiansen skrev:

> Det kan jeg også fint, men desværre kræver relationen så også,
> at det omvendte er tilfældet, og det ønsker jeg absolut ikke!

Det lyder mystisk - det er muligvis VS der driller.

> Det kan da ikke passe, at man ikke kan lave en relation, som
> kun checker den ene vej????

Nej, det kan ikke passe. Følgende script laver netop sådan en
relation (testet under SQL 2005 Express):


/***************************************************/
CREATE DATABASE test
GO
USE test
GO
CREATE TABLE A (X int PRIMARY KEY)
GO
CREATE TABLE B (X int PRIMARY KEY,
         CONSTRAINT fkA FOREIGN KEY (X) REFERENCES A(X))
GO
INSERT INTO A VALUES (1)
INSERT INTO A VALUES (2)
INSERT INTO A VALUES (6)

INSERT INTO B VALUES (1)
INSERT INTO B VALUES (2)
INSERT INTO B VALUES (3) -- Fejler på grund af constraint fkA

/***************************************************/

Husk at du ikke kan definere B.X som en IDENTITY COLUMN (mens A.X
godt kan være det).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns97CD6D2F525FDjcdmfdk@gyrosmod.dtext.news.tele.dk...

> Nej, det kan ikke passe. Følgende script laver netop sådan en
> relation (testet under SQL 2005 Express):
>
>
> /***************************************************/
> CREATE DATABASE test
> GO
> USE test
> GO
> CREATE TABLE A (X int PRIMARY KEY)
> GO
> CREATE TABLE B (X int PRIMARY KEY,
> CONSTRAINT fkA FOREIGN KEY (X) REFERENCES A(X))
> GO
> INSERT INTO A VALUES (1)
> INSERT INTO A VALUES (2)
> INSERT INTO A VALUES (6)
>
> INSERT INTO B VALUES (1)
> INSERT INTO B VALUES (2)
> INSERT INTO B VALUES (3) -- Fejler på grund af constraint fkA
>
> /***************************************************/


Tak for dit gode svar.

Nu er det sådan, at jeg forsøger at skabe relationen i VS2005's Server
Explorer vha. Database Diagrams.

Her skaber man relationen ved at trække X-kolonnen fra tabel B over på
X-kolonnen i tabel A.

Når begge kolonner er markeret som primary key, kan jeg *ikke* komme uden
om, at relationen bliver 1:1 (som virker *begge* veje). Det ser heller ikke
ud til, at jeg kan få min vilje ved efterfølgende at ændre på nogen af
relationens properties.

Når jeg ønsker, at X-kolonnen i tabel B skal være primary key, så er det jo
fordi jeg jeg gerne vil have, at der *højst* må være én række i tabel B, som
referer en given række i tabel A (men der *behøver* ikke at være det).

Bærer jeg mig helt tåbeligt ad?

Hvad er i øvrigt en Identity column?

--Martin.

---

Martin Christiansen skrev:

> Når begge kolonner er markeret som primary key, kan jeg *ikke*
> komme uden om, at relationen bliver 1:1 (som virker *begge*
> veje).

Har du afprøvet det?

Det at relationen er 1:1 betyder *ikke* nødvendigvis at den kører
"begge veje" - blot at der ikke kan være mere end én tilknyttet
post uanset om man starter fra A eller B. Hvis man vil have en helt
stringent notation, kan man kalde relationen "1:1?" eller
"1:[0-1]".


Jeg har ikke VS på denne maskine, men jeg har lige prøvet at
oprette relationen i SQL Server Management Studio Express (via
databasediagrammer) - og her er der ingen problemer.

Diagrammet viser det lille nøgle-ikon i begge sider af relationen
for at illustrere at feltet anvendes som primærnøgle i begge
tabeller - men det betyder ikke at FOREIGN KEY-afhængigheden går
begge veje.


> Hvad er i øvrigt en Identity column?

Et autonummereret kolonne - ofte anvendt som primærnøgle (da man så
kan lade databasen om at generere et unikt id-nummer).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns97CD777888EFjcdmfdk@gyrosmod.dtext.news.tele.dk...
> Martin Christiansen skrev:
>
> Har du afprøvet det?
>
Problemet er løst!

Jeg har lige prøvet det i et modelforsøg, og der virker det. Da jeg så gik
tilbage til min 'rigtige' databasemodel, virkede det tilsyneladende ikke,
men det viste sig ved nærmere eftersyn, at det var en *anden* constraint,
den løb ind i - ikke den imellem A og B. Jeg troede, det var den samme og
sluttede derudaf fejlagtigt, at constraint'en virkede i begge retninger.

Du har helt ret i, at bare fordi der er afbildet en nøgle i begge ender af
relationen (one-to-one), så virker constraint'en kun den *ene vej*, helt som
forventet og som ønsket.

Jeg undskylder meget for ulejligheden.

- Martin.

---

Støn! Den er alligevel gal! Problemet opstår, når der er 3 tabeller i spil:

Alle tre tabeller har en kolonne, X, som er primærnøgle.

A er hovedtabellen.

For tabel B skal gælde, at
1) Enhver række i B matcher præcis 1 række i A (vha. relation på kolonne
X)
2) Der må højst være 1 række i B, som matcher A

Tilsvarende gælder for tabel C, at
1) Enhver række i C matcher præcis 1 række i A (vha. relation på kolonne
X)
2) Der må højst være 1 række i c, som matcher A


Når jeg har lavet disse to relationer (ved først at trække fra kolonne X i
tabel B til kolonne X i tabel A, for derefter at trække en ny relation fra
kolonne X i tabel C til kolonne X i tabel A), kan jeg ikke længere indsætte
en række i tabel A alene (så får jeg at vide, at den ene af de to
constraints forhindrer det!).

Hvis jeg så fjerner den *ene* relation (ligemeget hvilken), så er der ingen
problemer imellem de to tilbageværende tabeller.

Det kan da ikke have sin rigtighed????

Og jo, jeg HAR forsøgt det i præcis det minimaleksempel, som er beskrevet
ovenfor.

Hvad er problemet?

---

"Martin Christiansen" <marcFJERNhr@mail1.stofanet.dk> writes:

> Hvad er problemet?

Hvilken SQL har du brugt til at lave dit minimale eksempel?
--
Thorbjørn Ravn Andersen

---

""Thorbjørn Ravn Andersen"" <nospam0000@gmail.com> skrev i en meddelelse
news:yu2irnvzm5f.fsf@luhmann.netc.dk...
>
> Hvilken SQL har du brugt til at lave dit minimale eksempel?


Hej, Thorbjørn.

Jeg har brugt Microsoft SQL Server 2005 (i Express udgaven - den som kommer
med VS2005).

---

"Martin Christiansen" <marcFJERNhr@mail1.stofanet.dk> writes:

> Jeg har brugt Microsoft SQL Server 2005 (i Express udgaven - den som kommer
> med VS2005).

Nej, hvilke SQL-udtryk har du brugt til at oprette det du beskriver?

--
Thorbjørn Ravn Andersen

---

""Thorbjørn Ravn Andersen"" <nospam0000@gmail.com> skrev i en meddelelse
news:yu2ejyjd1op.fsf@luhmann.netc.dk...
>
> Nej, hvilke SQL-udtryk har du brugt til at oprette det du beskriver?
>

Jeg har ikke selv skrevet SQL - det hele er sket vha. 'drag & drop' i Server
Explorer i VS2005 (vha. Database Diagrams). Se tidligere i tråden.

- Martin.

---

Martin Christiansen skrev:

> Jeg har ikke selv skrevet SQL - det hele er sket vha. 'drag &
> drop' i Server Explorer i VS2005 (vha. Database Diagrams). Se
> tidligere i tråden.

Prøv at højreklikke på databasen og vælg Tasks => Generate
Scripts... og lav et script over alle objekter.

Muligheden foreligger i SSMSE - jeg ved ikke om den også er der i
VS.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns97CD99E0977A7jcdmfdk@gyrosmod.dtext.news.tele.dk...
>
> Prøv at højreklikke på databasen og vælg Tasks => Generate
> Scripts... og lav et script over alle objekter.
>
> Muligheden foreligger i SSMSE - jeg ved ikke om den også er der i
> VS.

Den mulighed kunne jeg ikke finde i VS, men jeg fandt ud af noget andet -
nemlig at skifte view på databasen, således man i Server Explorers
træstruktur kunne se, hvilke constraints, der blev lavet på tabellerne, når
jeg i databasediagrammet 'trak' nye relationer imellem dem.

Her kunne jeg se, at når jeg trak en 1:1 relation fra tabel B til tabel A,
så blev der oprettet constraints på tabel A, og ikke på tabel B, som jeg
havde forventet! Konklusion: Hidtil har jeg tilyneladende trukket 1:1
relationerne den forkerte vej!

Fluks lavede jeg minimalforsøget igen (med tabellerne A, B og C, som
tidligere beskrevet), hvor jeg nu sørgede for at trække fra A til B og fra A
til C, og så virkede det som det skulle!

Ak ja, det er vel nok svært at være nybegynder...