[Access]Barcodes in een lange integer veld

[Briefcase]

Casus: Een access database met artikelnummers. Nu leek het mij het meest praktisch om de huidige artikelnummers om te zetten naar barcode-nummers, op de verpakking van producten bijv. 8716065003062.

Probleem is alleen dat dit nummer te hoog is voor een lange integer en dat Access het vertikt om een autonummering (sommige artikelen hebben geen barcode) te doen op een veld zonder lange integer.

Iemand enig idee?

[BertS]

Waarvoor ga je die barcodes gebruiken? Welke standaard?

[Gomez12]

Maar waar heb je het autonummeringsveld voor nodig??? Eenbarcodeveld mag bijna nooit autonummering zijn.
En waarom niet gewoon een extra veld naast artnr met de barcodes erin en dan iets van : if barcode=null then artikelnummer else barcode.

[Verwijderd]

Pak gewoon een datatype char of tekst ... zolang je er niet mee rekent maakt dit niks uit.

[Briefcase]

Het makkelijkste zou zijn een extra veld met barcodes en vervolgens een zoekveld. maar dan krijgen we het volgende:

Dit access-geval is gemaakt door een vriend van me; maar die grapjurk heeft met VB verschillende elementen van acces uitgeschakeld waaronder het kunnen bewerken van het formulier.

Nu heeft hij dus ook de VB code beveiligd met een wachtwoord. Dit is nogal vervelend want ik kan hem niet meer bereiken.

[Briefcase]

Verwijderd schreef op donderdag 14 juli 2005 @ 20:16:
Pak gewoon een datatype char of tekst ... zolang je er niet mee rekent maakt dit niks uit.

de createur van de database is met expressies aan het goochelen geweest waardoor het formulier op hol slaat bij een tekst aanduiding. Met een dubbele precisie krijg ik de meest grappige regels in mijn tabel. En datatype char ben ik niet tegen gekomen.

[TheLunatic]

Je zou hier sowieso geen integer-veld willen, want zo'n barcode kan best met een 0 beginnen lijkt me, en een integer kan dat niet. Dus gewoon een id-veld met autonummering, en een barcode-veld (character/string) met je barcodes. Als tekst, dus.

[BertS]

Briefcase schreef op vrijdag 15 juli 2005 @ 14:11:
Dit access-geval is gemaakt door een vriend van me; maar die grapjurk heeft met VB verschillende elementen van acces uitgeschakeld waaronder het kunnen bewerken van het formulier.

Nu heeft hij dus ook de VB code beveiligd met een wachtwoord. Dit is nogal vervelend want ik kan hem niet meer bereiken.

Hij zal er wel een reden voor (gehad) hebben...
En het is nog steeds een vriend van je?

[Briefcase]

bee-es schreef op vrijdag 15 juli 2005 @ 15:31:
[...]

Hij zal er wel een reden voor (gehad) hebben...
En het is nog steeds een vriend van je?

yeah right

[Verwijderd]

TheLunatic heeft gelijk.
De laatste positie van in Europa gangbare barcodes (positie 13) is namelijk een checkdigit die wordt bepaald uit de voorgaande 12 posities:
Rechter cijfer uit de som 1000 - 1*(alle waarden van oneven posities)-3*(alle waarden van even posities).
voorbeeld van EAN-13 (boek) 9789038884370
1000-1*(9+8+0+8+8+3)+3*(7+9+3+8+4+7)=850, dus checkdigit 0
Sigaretten hebben soms een visueel kortere EAN (8 posities) o.a. omdat meer posities niet op de verpakking passen. Om toch een geldige checkdigit volgens hetzelfde systeem te krijgen worden er op de achtergrond 5 nullen voor de ze code geplaats.
voorbeeld van EAN-8 (shagvloeitjes) 0000054034013
1000-1*(0+0+0+4+3+0)+3*(0+0+5+0+4+1)=963 dus checkdigit 3

Voor deze EAN-8 is het dus noodzakelijk dat de voorloopnullen op de juiste plaats staan en moet het dus een alfanumeriek veld zijn in Access