---

Jeg har en Access Database ”bruger”.
Jeg har en tabel ”brugerinfo”.
I brugerinfo har jeg et feltnavn der hedder ”vismig”.
”Vismig” kan være et eller flere tal fra 1 – 600.
Brugeren skal vælge et eller flere ”vismig”-tal, f.eks. 20, 23,
88, 165, 290, 400, 569, etc.
Dette skal ske ved brug af checkbox.
Kan jeg eller hvordan samler jeg alle disse værdier?
Kan man have flere forskellige talværdier i et felt i databasen,
umiddelbart kan jeg kun få et tal ind?
M.v.h.
Michael

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Michael Tillgaard skrev:

> ”Vismig” kan være et eller flere tal fra 1 – 600.

Det er en rigtig dårlig ide. Man bør aldrig gemme mere end én værdi i et
felt - det er første (og altså den mest basale) normalform for
databaser.

Se evt. tråden her:
<http://groups.google.dk/groups?hl=da&lr=&threadm=pan.2005.02.20.11.01.38.833305%40arvin.dk&rnum=1&prev=/groups%3Fsourceid%3Dmozclient%26ie%3Dutf-8%26oe%3Dutf-8%26q%3Dbryder%2Bnormalform>


> Dette skal ske ved brug af checkbox.
> Kan jeg eller hvordan samler jeg alle disse værdier?

Brug samme navn, men forskellige værdier:

   <input type="checkbox" name="foo" value="12" />
   <input type="checkbox" name="foo" value="25" />
   <input type="checkbox" name="foo" value="117" />

Et request på sådan en form vil returnere alle valgte værdier som en
kommasepareret liste (hvis der fx er hak i de to sidste bokse ovenfor,
vil Request.Form("foo") give "25,177".

> Kan man have flere forskellige talværdier i et felt i databasen,
> umiddelbart kan jeg kun få et tal ind?

Hvis din felttype er "tal", kan du ikke lægge flere værdier ind. Den kan
godt gøres i et tekstfelt, men som nævnt ovenfor er det en *meget*
dårlig ide. Lav i stedet din tabelstruktur om (typisk ved at indføre en
undertabel) og indsæt tallene enkeltvis.

--
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:9ikcuivhww7c$.dlg@jcdmfdk.invalid...
> Michael Tillgaard skrev:
>
>> "Vismig" kan være et eller flere tal fra 1 - 600.
>
> Det er en rigtig dårlig ide. Man bør aldrig gemme mere end én værdi i et
> felt - det er første (og altså den mest basale) normalform for
> databaser.

Som er den mest rodede og mindst effektive af normalformerne, men det er
ikke dem, vi skal tale om her.

Det er rigtigt, at man kun kan gemme én værdi i et felt, men derfor kan man
da godt tænke sig om. Løsningen på dit problem kaldes bitmapping. Således
returnerer den første checkboks værdien "1", den næste "2", den tredje "4"
og så fremdeles, idet værdien hele tiden fordobles. Når du skal gemme
værdien i databasen, lægger du blot værdien af de valgte checkbokse sammen
og gemmer summen. På den måde kan du gemme enhver tænkelig kombination af 32
checkbokse i et felt af typen "Langt Heltal".

Har du f.eks. tre checkbokse, og brugeren har afkrydset nr. 1 og nr. 3,
giver det summen 5, som gemmes i databasen. Tricket er så at afkode værdien
igen, men det er heller ikke så svært. Du skal bare begynde med den
checkboks, der sætter den højeste værdi. I dette eksempel checkboks nr. 3,
som bidrager med værdien 4.

Denne trækker du fra den læste værdi

5 - 4 = 1

Da det giver en værdi, der er større end eller lig med 0, var checkboksen
afkrydset af brugeren, og vi arbejder videre med det fundne resultat (1).
Fra det trækker vi den værdi, som checkboks nr. 2 vil bidrage med

1 - 2 = -1

Her får vi et tal, der er mindre end 0, så checkboks nr. 2 var ikke
afkrydset. Så vi fortsætter med samme tal og den værdi, checkbox nr. 1
bidrager med

1 - 1 = 0

Dette giver også et resultat, der er større end eller lig med 0, så denne
checkboks var også afkrydset. Får du på et tidspunkt resltatet 0 som her,
kan du bruge det som stopklods, da der ikke vil være flere checkbokse, der
var afkrydset, også selv om du mangler at undersøge nogle stykker.

Da du begynder afkodningen med den største værdi, gør du dig selv en stor
tjeneste, hvis du lader den første checkboks returnerer den højeste værdi og
så halverer værdien fra checkboks til checkboks, så den sidste checkboks
returnerer værdien 1. Det gør det lettere at lave siden, da alle checkbokse
kan laves under afkodningen.

Har du god plads kan du også gemme indstillingen i et strengfelt, idet du
lader hvert tegn i strengen repræsentere en checkboks. På den måde kan du
gemme indstillingerne for op til 255 checkbokse i ét felt.

Du starter her med en tom streng, og hvis en checkboks er afkrydset,
tilføjer du tegnet "1" til strengen. Er den ikke afkrydset, tilføjer du i
stedet tegnet "0" til strengen. I eksemplet ovenfor giver det strengværdien

"101"

som gemmes i databasen. Afkodningen er endnu lettere end ovenfor, da du blot
skal gennemløbe strengen tegn for tegn. Et det et "1", skal du afkrydse
checkboksen, mens den ikke skal afkrydses, hvis tegnet er et "0".


--
Mvh


C@rsten

---

Carsten Pedersen skrev:

[om 1. normalform]

> Som er den mest rodede og mindst effektive af normalformerne,

Hvad mener du? Hvis du skal bringe en database på en højere
normalform end den første (hvad der bestemt er en god ide), er man
da nødt til at starte med at opfylde første normalform.


> Det er rigtigt, at man kun kan gemme én værdi i et felt,

Nja - man *bør* kunne gemme én værdi pr. felt, men det kan da fint
lade sig gøre at gemme flere - fx som en kommasepareret liste.


> Løsningen på dit problem kaldes bitmapping.

[snip]

> På den måde kan du gemme enhver
> tænkelig kombination af 32 checkbokse i et felt af typen
> "Langt Heltal".

Det er vist ikke nok hvis det oprindelige krav for input skal kunne
honoreres: '"Vismig" kan være et eller flere tal fra 1 - 600.'

Bitmapping kan ganske rigtigt være smart - men kun med et begrænset
antal mulige inputværdier.


> Tricket er så at afkode værdien igen, men det er heller ikke så
> svært.

Det kan gøres nemmere end den metode du har vist, ved hjælp af
bitsammenligning:

If bitsum AND 1 Then
   ' Første (mindste) bit sat (1 indgår i summen)
End If
If bitsum AND 2 Then
   ' Anden bit sat (2 indgår i summen)
End If
If bitsum AND 4 Then
   ' Trejde bit sat (4 indgår i summen)
End If
....
If bitsum AND (2^n) Then
   ' n+1' bit sat (2^n indgår i summen)
End If

(se evt. <http://www.dx21.com/SCRIPTING/VBSCRIPT/MATH.ASP>)
--
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:Xns9606EA991CD07jcdmfdk@gyrosmod.cybercity.dk...
> Carsten Pedersen skrev:
>
> [om 1. normalform]
>
>> Som er den mest rodede og mindst effektive af normalformerne,
>
> Hvad mener du? Hvis du skal bringe en database på en højere
> normalform end den første (hvad der bestemt er en god ide), er man
> da nødt til at starte med at opfylde første normalform.

Med et fornuftigt ER-diagram omsat korrekt til tabeller, starter man gerne i
mindst 3. normalform.

>
>
>> Det er rigtigt, at man kun kan gemme én værdi i et felt,
>
> Nja - man *bør* kunne gemme én værdi pr. felt, men det kan da fint
> lade sig gøre at gemme flere - fx som en kommasepareret liste.
>
>
>> Løsningen på dit problem kaldes bitmapping.
>
> [snip]
>
>> På den måde kan du gemme enhver
>> tænkelig kombination af 32 checkbokse i et felt af typen
>> "Langt Heltal".
>
> Det er vist ikke nok hvis det oprindelige krav for input skal kunne
> honoreres: '"Vismig" kan være et eller flere tal fra 1 - 600.'

Han bruger vel ikke alle 600 værdier? For så hjælper en kommasepareret liste
ham heller ikke meget. Desuden vil jeg nødigt gå i krig med en hjemmeside
med 600 checkbokse. Den vil være både sløv og uoverskuelig.

> Bitmapping kan ganske rigtigt være smart - men kun med et begrænset
> antal mulige inputværdier.

32 eller 255 værdier er naturligvis en begrænsning, men det rækker da langt.
Og der er da ingen, der forbyder ham at lave en lille funktion, der kan
omsætte et bitnummer til et tal, der giver mere mening for hans ASP-side.
Det kan en Select Case-konstruktion gøre meget til.
>
>> Tricket er så at afkode værdien igen, men det er heller ikke så
>> svært.
>
> Det kan gøres nemmere end den metode du har vist, ved hjælp af
> bitsammenligning:
>
> If bitsum AND 1 Then
> ' Første (mindste) bit sat (1 indgår i summen)
> End If
> If bitsum AND 2 Then
> ' Anden bit sat (2 indgår i summen)
> End If
> If bitsum AND 4 Then
> ' Trejde bit sat (4 indgår i summen)
> End If
> ...
> If bitsum AND (2^n) Then
> ' n+1' bit sat (2^n indgår i summen)
> End If

Nu ved jeg ikke hvilket niveau, Michael ligger på rent
programmeringsmæssigt. Men bitvis AND og bitvis OR er ikke lige det, der er
nemmest at kapere for en, der ikke er vant til at programmere. Defor
foreslog jeg en metode, der er noget nemmere at forstå for en, der ikke er
så erfaren udi programskrivning.


--
Mvh


C@rsten

---

Carsten Pedersen skrev:

> Med et fornuftigt ER-diagram omsat korrekt til tabeller, starter man gerne i
> mindst 3. normalform.

Nu har spørgeren tydeligvis ikke anvendt et "fornuftigt ER-diagram" til
at lave databasen efter. Min pointe er ikke at man skal nøjes med 1.
normalform, men at man skal tænke sig rigtig godt om inden man bryder 1.
normalform.


> Han bruger vel ikke alle 600 værdier?

Når han skriver værdier fra 1-600 går jeg ud fra at de alle er i spil.
Det kan godt tænkes at der ikke skal gemmes mere end 1-10 kombinationer
af værdierne i feltet, men det hjælper ikke når der stadig er 600 mulige
inputværdier.

Det er ikke så meget antallet af kombinationer som det er antallet af
mulige inputværdier der sætter begrænsningen for bitmapping.


> Nu ved jeg ikke hvilket niveau, Michael ligger på rent
> programmeringsmæssigt. Men bitvis AND og bitvis OR er ikke lige det, der er
> nemmest at kapere for en, der ikke er vant til at programmere. Defor
> foreslog jeg en metode, der er noget nemmere at forstå for en, der ikke er
> så erfaren udi programskrivning.

Man behøver ikke nødvendigvis forstå den bagvedliggende teknik for at
bruge bitvis AND. Når man kun arbejder med enkelte bitværdier (potenser
af 2, synes jeg metoden er meget let at gennemskue. I din metode skal
man sørge for at behandle alle bits i den rigtige rækkefølge, samt holde
styr på at der i nogle tilfælde skal trækkes en værdi fra og i andre
tilfælde skal værdien ikke trækkes fra. Fælles for de to metoder er at
man skal bruge de enkelte bitværdier (1, 2, 4, 8, ...) - det slipper man
ikke for. Med ved at benytte bitvis AND kan man behandle
bitforespørgsler uafhængigt af hinanden.

--
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:1tj1qt2za4blm.dlg@jcdmfdk.invalid...
> Carsten Pedersen skrev:
>
>> Med et fornuftigt ER-diagram omsat korrekt til tabeller, starter man
>> gerne i
>> mindst 3. normalform.
>
> Nu har spørgeren tydeligvis ikke anvendt et "fornuftigt ER-diagram" til
> at lave databasen efter. Min pointe er ikke at man skal nøjes med 1.
> normalform, men at man skal tænke sig rigtig godt om inden man bryder 1.
> normalform.


Som jeg nævnte allerede i mit første indlæg, drejer diskussionen sig ikke om
normalformer, og jeg ville såmænd aldrig have nævnt dem i mit andet, hvis du
ikke selv havde bragt det på bane igen.

>> Han bruger vel ikke alle 600 værdier?
>
> Når han skriver værdier fra 1-600 går jeg ud fra at de alle er i spil.
> Det kan godt tænkes at der ikke skal gemmes mere end 1-10 kombinationer
> af værdierne i feltet, men det hjælper ikke når der stadig er 600 mulige
> inputværdier.
>
> Det er ikke så meget antallet af kombinationer som det er antallet af
> mulige inputværdier der sætter begrænsningen for bitmapping.


Michael skriver selv, at det er noget brugerinfo, han vil gemme. I mine ører
lyder det mere som om, han vil gemme en opsætning end resultaterne af et
spil, han vil gemme. Og så er antallet af kombinationer da en væsentlig
faktor.

>> Nu ved jeg ikke hvilket niveau, Michael ligger på rent
>> programmeringsmæssigt. Men bitvis AND og bitvis OR er ikke lige det, der
>> er
>> nemmest at kapere for en, der ikke er vant til at programmere. Defor
>> foreslog jeg en metode, der er noget nemmere at forstå for en, der ikke
>> er
>> så erfaren udi programskrivning.
>
> Man behøver ikke nødvendigvis forstå den bagvedliggende teknik for at
> bruge bitvis AND. Når man kun arbejder med enkelte bitværdier (potenser
> af 2, synes jeg metoden er meget let at gennemskue. I din metode skal
> man sørge for at behandle alle bits i den rigtige rækkefølge, samt holde
> styr på at der i nogle tilfælde skal trækkes en værdi fra og i andre
> tilfælde skal værdien ikke trækkes fra. Fælles for de to metoder er at
> man skal bruge de enkelte bitværdier (1, 2, 4, 8, ...) - det slipper man
> ikke for. Med ved at benytte bitvis AND kan man behandle
> bitforespørgsler uafhængigt af hinanden.


Det tror jeg ikke en nybegynder vil være enig med dig i. De vil som regel
gerne kunne forstå, hvad det er, deres program laver. Ellers er de helt
lost, hvis det ikke gør som forventet. Jeg har set adskillige, der havde
"tilt" stående i øjnene, når snakken faldt på bitvise operationer, da de
ikke fattede en klap af, hvad de gjorde, og hvordan de skal bruges. Hvad der
synes enkelt for en erfaren programmør, behøver bestemt ikke være det for
en, der ikke er så erfaren.

Men jeg synes, Michael selv skal afgøre, hvad der er bedst for ham og hans
løsning. Så kan han jo spørge igen, hvis han har brug for hjælp.

Mvh


C@rsten

---

Carsten Pedersen skrev:

> Men jeg synes, Michael selv skal afgøre, hvad der er bedst for
> ham og hans løsning. Så kan han jo spørge igen, hvis han har
> brug for hjælp.

Her er vi i hvert fald enige
--
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