Brugere skal altid have samme ID-numre

you can NOT! There is no such thing as 100%!

Så lad os sige 99%.

Hvis jeg tildeler hver bruger et autonummer, er jeg jo nødt til at være rimelig sikker på, at brugeren og ID-nummeret "passer sammen", når der reffereres mellem flere tabeller.
Men det er måske bedre at bruge det unikke brugernavn i stedet for et ID-nummer?

I dont know exactly what your program does but if I were you I would give each user a unique ID, maybe use their initials OR if they alreadyhave an employee number or something then use that. Its also easier to remeber if it is used other places.

Jeg kan sagtens bruge deres brugernavn i stedet for et ID-nummer. Min eneste bekymring er, at databaserne hurtig vil blive store.
Hvis jeg f.eks. har 100000 poster med et brugernavn (3-20 tegn) vil det jo fylde en del mere end, hvis det var ID-numre (1-1000 tegn)

Rettelse: ID-numre (1-4 cifre)

IF you use an Autonumber field for each user then this will be unique for each user you create. And as long as your database is normalized then it should give NO problems at all!

Præcis! Men hvis den så bliver komprimeret, kommer der jo pludselig rod i ALT.

Og den er vel nødt til at blive komprimeret en gang i mellem...

Komprimering ødelægger ingenting !! - Du bruger jo ID'et til at identificere dine records... og ikke til at tælle dem med, og der er DER at folk får problemer...

Jeg har bare brugt brugernavnet som ID indtil videre, fordi jeg har hørt så meget dårligt om autonummerering. Og det er jo væsentligt at folk ikke pludselig kan læse hinandens breve m.v.
Men hvis jeg f.eks. har en tabel med - lad os sige 400 brugere - idenficeret med ID-numre fra 301-800, og jeg så komprimerer den "manuelt" i Access. Vil numrene så ikke komme til at hedde 1-400 i stedet?
I så fald vil det jo skabe rod i det hele...

[Brugere]: ID (autonummer), Navn (Text50)... osv

id bliver da unikt, og om der står 9 eller 548653754 betyder intet for dig, da det kun bruges til intern reference. Du laver så et opslag i din brugertabel, for at finde navnet på den pågældende bruger.

Ja, men hvis der f.eks. er sendt et brev til "Steen" fra "Torben", vil jeg ikke risikere, at der i Steens udbakke står, at han har sendt brevet til "Mona", der har et andet ID-nummer.

Komprimering...  Ændrer ikke ved eksisterende ID-numre, men sætter "næste nye nummer" til at være det største nummer + 1. Og det er hér at folk får problemer, da de netop tror at de kan "genbruge" numre ved at komprimere.

Så jeg ville absolut overveje at bruge ID-numre, da de fylder væsentlig mindre!

Dit eksempel med brugere 301-800 vil resultere i at næste bruger vil hedde 801, uanset om du komprimerer eller ej!

Jeg er temmelig sikker på, jeg så et spørgsmål her på E., der lød på, hvordan man får ID-nummeret til at starte med "1", hvis f.eks. nr. 1-13 var blevet slettet.
Og svaret lød så vidt jeg husker, at man bare skulle komprimere databasen - så ville pladserne det hele "rykke ned" og starte med 1 i stedet for 13.....?!

Jeg er nemlig i gang med at lave en tabel, kun indeholdende ID-numre, der reffererer fra det ene til det andet, og det er umiddelbart fuldstændig intetsigende. Derfor ville jeg gerne være sikker på, at de numre, som brugerne til at starte med har fået tildelt ikke står og ændrer værdi, uanset hvad jeg end gør (lige bortset fra at opdatere ID-feltet)

IF 1-13 have been removed then you will be able to re-use them, but it WILL require code to do this. Another thing! A user may no longer be employed doesnt mean that this user gets deleted! It should be set to inactive. This is because OTHER tables will be related to this person and either they get deleted OR the user gets re-set to another user.

Undskyld - hvad bør sættes til "inaktiv"?

Nååh... brugerne... ja, men det er ikke noget problem, for hvis en bruger vælger at slette profilen opdateres alle referencer automatisk, så det hele passer sammen.

so if user ID = 1 gets deleted then it is available again for a new user, so there i sno problem!

Tak for hjælpen! :)