Jeg er ved at lave db, der skal indeholde en helt del serienumre, der skal scannes ind i db'en når vi sender vores produkter ud af huset.
Det jeg leder efter er, en eller anden form for indlejret tabel hvor jeg kan scanne en masse serienumre ind i pr. ordre, samtidig med tabellen tæller antallet af scannet linier op. Det kan være ret svært at huske på hvor mange numre man har scannet, hvis der eksempelvis er 200 linier, der skal scannes på samme ordre!!
Det er sikkert nem, kan bare ikke lige gennemskur hvordan jeg får det sat sammen i den formular jeg har lavet til formålet ;-)
Normally I would think that you would have a form with a field where the "serienumre" is scanned. It would be quite simpl eto have an extra field on the form which shows you how many you have scanned.
The extra field is just a calculated field which counts teh number scanned for that order, it isnt stored in a table but tit isnt necessary as it can alwasy be re-calculated.
Men hvordan skal jeg lavet det felt, og hvilken type skal det være? Jeg har brug for en eller anden form for type, der kan indeholde mere end 255 tegn. Derfor har jeg tidligere brugt et notatfelt, men der bliver alle serinumrene lagt i en lang smøre uden mellemrum.....
Synes godt om
Slettet bruger
07. februar 2008 - 13:15#4
Du er nød til at få det ind et serienummer af gangen i et tekstfelt, sådan at du får dem ind i en tabel, som gemmer ordrenr og et scannet serienummer. Du kan sikkert have en formular åben hvor du har indtastet ordrenr en gang for alle. Så kan du have en underformular, som viser serienumre, dvs. at dem bygger på din tabel, måske er du nød til at opdatere (requery) for hver scanning (jeg ved ikke hvordan scanneren virker). Under alle omstændigheder så i formularfoden af denne underformular laver du et tekstfelt, hvor rækkekilden er: =Count([NavnPåSerieNrFelt])
I have no idea how your database is designed but normally in an order dB would have one table (OrderHeader) which contains the information concerning the order. Customer information, order number, order date etc. Then another table (OrderDetail) which contains the order items (serienumre). So it isnt necessary to have one field containing all "serienumre".
If you havent designed your databases (tables/fields) yet then i would suggest that you do this first. Then when that is in place go on to designing yur forms etc.
When a "serienumre" is scanned it gets added to the OrderDetail
Jeg kan ikke helt gennemskue jeres løsninger, idet jeg gerne skulle ende op med en db, hvor jeg indtaster alle generelle oplysninger en gang (Ordrenr., kundenr., Ref.) samtidig med jeg bare kan scanne løs i mit serienummer felt. Hvis jeg har mange scanninger pr. ordre vil jeg ikke ende op med, at jeg skal gøre noget manuelt hver gang et serienummer scannes. Typisk har jeg et par hundrede serienumre pr. ordre, hvor det gerne skule gå ret hurtigt!!
Men du skal regne med at komme igang med en stor opgave, det er lidt komplext..
Hvis det er til en virksomhed, ville jeg købe et lille erp, og modde det.. ex stellar office (tror det er 1000kr i oprettelse og et par hundrede om mdr.).. pengene er i hvert fald lagt godt ud hvis man tager tiden det vil tage at udvikle selv.
Hmmm, ok - tak for svarene!! Men jeg tror i gør det lidt mere komliceret end som så. Jeg har bare brug for en simpel db i access, der køre helt seperat ved siden af vores ERP-system, og som vores lagermand blot skal scanne ordrenumre ind i. I mit tidligere arbejde havde vores IT-chef "snittet" en meget meget simpel db i access til at udføre den opgave, og det var egentlig derfor jeg troede det var lige til!
we are still talking "simpel db I access" but there is a difference between simple right and simple wrong
Synes godt om
Slettet bruger
08. februar 2008 - 11:10#13
Det er sikkert lige til og selvfølgelig kan det laves helt simpelt, men jeg ville personligt være nød til at sidde med scanneren, for at kunne lave det og det vil altså tage nogle timer!~)
If you read the comment form jokkejensen 07/02-2008 15:28:14 he suggest how the tables in the dB could look. You are suggesting that only one table is needed which I say is wrong. Scanning all "serienumre" into the same field for a single or will give other problems later, for example making a list of serienumre for a given order, find all orders where a given serienumre is used. These are very simple tasks in a normalized databases.
Synes godt om
Slettet bruger
08. februar 2008 - 11:13#15
Ja, ja... alt er relativt!~)
Synes godt om
Slettet bruger
08. februar 2008 - 11:17#16
Den kommentar gav vist ikke megen mening....
Jeg tror jeg har gang i for meget, så jeg går lige en tur i pakkeriet og skifter en mus. Det ved man da hvad er!~)
spg, I didnt see your comment 08/02-2008 11:10:29 my comment 08/02-2008 11:11:40 wasnt directed at yours but a further comment to lautorp78.
lautorp78 I'm only trying to help you d things right becasue I know from experience that doing it "quick and simple" from the start will very likely give you meny problems later.
If you design the dB correctly from the start you will find that things are still simple
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
