Problemer med nøgler

If you have relationships in the main table then it require sthat you select a record from the related table. Otherwise you will be trying to create a record with NULL (NOTHING) in a foreign key field. You can also alter the design of the table to ALLOW NULLS

Hello Terry:

I try it, and will come back :)as soon as p..

Mandersen

mandersen>It simportantto decide what your requirements are. Must you be allowed to create a record in one table WITHOUT a value in the foreign key fiels (the field which references the other table)

;) terry - tja kan jo kun sige jeg er enig

er nok normaliseringen der er problemet eller hur. Er jo lidt svært at sige når tabellerne ikke er listet

Glad to hear that you agree Susanne :o)
mandersen. In the property for the foreign key field set the required to NO and the indexed to YES(Diplicates allowed) This will allow you to crea´te a record WITHOUT entering data in this field. But IF the field is required then leave it as YES (required)

;)) terry sorry couldn´t stop my self

>> mandersen hvis terrys forslag mod forventning ikke skulle virke GH
så prøv lige at list din tabeller op - samt en lille historie om hvodan de skal hænge sammen

Tak for hjælpen indtil videre (begge to)<:)
Jeg holder fri i aften,"måske" det er jo svært når skidtet ikke virker..
men jeg vender tilbage hurtigst muligt.
jeg kan jo snart ikke undvære jeres gode råd.hehe

Hilsen Mandersen

;) by the by mandersen du behøver ikke sætte 100 p på højkant. Du bestemmer det selvf. selv, men normalt er et sp til 60 p at betragte som svært....

Hej Susanne har du en mail så sender jeg tabellerne + forspørgsel-

Hilsen Mandersen

;) tjo hvorfor ikke
du kan sende den til susbbl@hotmail.com
kan du ikke lige skrive hvad det er jeg skal kigge på, samt hvilke forudsætninger du har forestillet dig databasen skal opfylde

dB modtaget
Prøver lige at se om jeg kan nå kigge lidt på den nu. Ellers bliver det først i aften......

>>Mandersen Hvorfor har du en 1 til 1 relation mellem tabellerne VÆRKSTED og PARTNUMMER ?

På nuværende har du flg 3 tabeller

PARTNR
- plads id (P-nøgle)
- pn/iv
- ln
- udsbet
- fab_typ
- nor
- pubref
- kapacitet
- bem
- rnr_nr
- kal_type

VÆRKSTED
- plads id (f-nøgle)
- skab
- hylde/dør
- kasse
- snr
- pris
- år
- kal_date
- nextka
- rum

RUMNUM
- Rum (p-nøgle)
- Rumnavn

Kan godt være det er mig der er dum men jeg forstår ikke helt dine forkortelser - sorry ;)

Er det meningen at du ønsker at registrere hvor en specifik dims besinder sig henne og hvad den koster. Feks.
Dims nr 1 er på plads nr A på værkstedet i rum nr. X og koster 1,- kr ??

Jeg bliver nødt til at have lidt flere informationer, da jeg på nuværende ikke helt er med på hvad du ønsker din database skal kunne håndtere....

Det er rigtigt at jeg ønsker  at registrere og søge,,,, 1 til 1 relationen er muligvis forkert,,, men hvad går der galt med rum-nøglen osv...
værksted/partnr kører okay..håber det kunne gi noget.

:)

Dine tabeller er ikke normaliseret helt som de skal være

Jeg har brug for at vide hvad der er unikt for tabellen Værksted. Hvad er det helt preæcist for data den skal indeholde. Og hvilke data er det meningen der skal registreret i tabellen PARTNR

øhmmm i tabellen PARTNR er det vel meningen at du registrer de enkelte enheder, hvad de koster osv

umiddelbart er min første indskydelse at pris og snr skal over i den anden tabel - hvad er det for en pris ? Er det prisen på en enhed fra tabellen PARTNR, eller ???

de data du registrerer i PARTNR - findes der her kun 1 enhed af hver slags ?

HVis det hænger sådan sammen som jeg umiddelbart tror, så skal du have endnu en tabel, der forbinder VÆRKSTED og PARTNR. Der skal oprettes en P-nøgle i VÆRKSTED. Der skal så nøglekopieres fra VÆRKSTED og PARTNR over i den nye tabel

..........hvis det vel og mærke er sådan at et værksted har mange partnumre og det enkelte partnummer findes der flere af på værkstedet. U get what I mean ??
Hvis korrekt - så har du en mange-til-mange-relation mellem VÆRKSTED og PARTNR, og den duer ikker. Er for bøvlet at arbejde med i Access....

Bliver nødt til at vende tilbage senere - er på job lige i øjeblikket :)

Hej:
Du har ret mine tabeller er ikke normaliseret helt som de skal være

(rum)  er unikt for tabellen Værksted.
Tabellen (værksted) skal fortælle hvor delen befinder sig. (Hvilket værksted og rumnr)

I tabellen PARTNR er det  meningen at jeg registrer de enkelte enheder, hvad bemærkninger, lagernr, type, kalibrerings type/dato osv

”umiddelbart er min første indskydelse at pris og snr skal over i den anden tabel - hvad er det for en pris ? det er prisen på en enhed fra tabellen PARTNR, eller ???” ja det er prisen/serienr  på
enheden

de data jeg registrerer i PARTNR - kan der findes flere enheder af hver slags ?

Det er sådan at der er flere værksteder og de har mange partnumre, der kan være ens, og det enkelte partnummer kan findes på flere af på værkstedet… da der kan være flere af samme slags enheder


det hænger sådan sammen som du umiddelbart tror, men hvordan kæder jeg så de tabeller du mener sammen med de andre??
du mener endnu en tabel, der forbinder VÆRKSTED og PARTNR. Der skal oprettes en P-nøgle i VÆRKSTED. Der skal så nøglekopieres fra VÆRKSTED og PARTNR over i den nye tabel..
but how???
Håber du kan hjælpe
Vil du sende mail med tabellerne vil jeg blive meget))))))))))):)

Hilsen
Mandersen

håber opgaven kan løses...
hilsen
Mandersen

ok så har jeg lidt mere at arbejde ud fra... Er lige kommet hjem fra arbejde. Tager lige en bid mad, så vender jeg tilbage

Hej.
I værksted skal du lave felted rum om til placering.
I rumnummer. Opretter du felterne RumNr + HyldeNr.
Det skal løse sidste del af dit problem.
Vh Henrik

ok nu har jeg leget en del

om det er det du ønsker - tja nu får vi se
Som du kan se har jeg foretaget en del ændringer. Du har nu 5 tabeller

tblVaerksted  - Her registrerer du stamdata på værksted, som f.eks.
- VaerkstedsID (p-nøgle)
- Navn (navnet på værkstedet)
- Adresse
- Postnr (den berygtede er her f-nøgle)

(umiddelbart er jeg ikke helt sikker på du kan nøjes med kun at oprette en P-nøgler her, derfor har jeg oprettet et index, så der både tjekkes på nøglen og navnet, så du ikke kommer til at oprette dubletter, da det enkelte værksted jo kun skal oprettes EN gang i denne tabel - vil lade det være op til dig om der skal indekseres andre steder. Prøv at oprette et værksted med samme navn som en af dem jeg allerede har oprettet - så ser du ideen med et index)

tblPartnr (her reg. du dine dimser ;))
- PartnrID (p-nøgle)
- Navn (navnet på dimsen)
- PN/IV
- UDSBET
- FAB_TYP
- NOR
- PUBREF
- KAPACITET (ved ikke om det er det samme som antal ?)
- BEM
- PNR_NR
- KAL_TYPE
- Pris
- SNR (serienr ??)
- Antal på lager (overflødig, eller ?)

tblPartPlacering
- VaerkstedsIDRef (f-nøgle, men samtidig p-nøgle. Hentes fra tblVaerksted)
- PartnrIDReg (f-nøgle, men samtidig p-nøgle. Hentes fra tblPartnr)
- Skab
- hylde/dør
- Kasse
- Kal_date
- Nextka
- RumIDRef (f-nøgle fra tblRumNummer)

Ideen med denne tabel er at her har du mulighed for at kunne registrere at den enkelte dims findes hos flere værksteder (jeg har oprettet en formlar frmVaerksted med tilhørende underformular (frmVaerkstedU), så kan du se princippet i denne opdeling. Se lidt på forespørgslerne, giver et overblik over hvordan jeg har oprettet formularerne

tblRumnummer (her registreres de enkelte lokaler)
- RumID (p-nøgle)
- RumNavn (navnet på lokalet)

tblPostnummer (den obligatoriske tabel, hvis du da overhovedet ønsker at kunne se denne info)
- Postnummer (p-nøgle)
- By

Læg mærke til at jeg gør flg. når jeg nøglekopierer. Ex PartnrID kopieres til tblPartPlacering => at jeg så giver nøglen navnet PartnrIDRef. Skaber overblik, da du så er klar over der er tale om en kopieret nøgle. Overholder her ikke de gyldne normaliseringsregler LOL, men det skaber overblik...

Phew en ordentlig smøre
Er spændt på din tilbagemelding. Konverterer lige basen til 97 og sender den til dig ;)

Tak for indsatsen "alle."

:) Mandersen

var så lidt og tak for p

var det sådan noget i den stil du skulle bruge ?

HEJ Susanne:)
Jeg håber at det falder i hak nu.
ha det godt.
det kan være jeg vender tilbage og bruger en livlinie,
og spørger publikum.he he
:)
mandersen

;) du skal da være så velkommen
det er jo derfor vi er på E G***

Access kan nu også godt være ret kringlet indimellem