Waar zitten er fouten in?? én wat zit er nog meer in die dromen van me :)

[jok078]

Hoi,

In bijlage vind je mijn mdb. (Ingezipt)

Ik heb het opgebouwd, maar denkelijk zitten er in de basis enkele fouten waardoor het niet goed werkt Weet jij ze te vinden

De opbouw van formulieren heb ik voorlopig nog niet gedaan omdat het daar steeds misloopt. Heb ze steeds gewist...

Even ter verduidelijking...

• We hebben een tabel met klanten: TBL_Naam (misschien wordt dit toch betere TBL_Klant - tsjah, ben zo begonnen, weet net of het nog te veranderen is zonder problemen te creëren)
• We hebben een tabel met enquetes: TBL_Enquete - Een Klant kan meerdere enquetes invullen. - Er kunnen verschillende enquetes bestaan, met andere vragen.
• We hebben een tabel met Bestellingen: TBL_Bestelling - Een klant kan meerdere bestellingen doen, op verschillende data ect., met hierin verschillende producten (bijv. 10 - weet niet of hier een limiet op moet - ik was begonnen door dit in TBL_Bestelling Product01, Aantal01 te noemen - weet je een andere manier om dit ongelimiteerd te maken - graag, dan leer ik weer wat bij :love
• Momenteel heb ik nog een TBL_Contact...
  Idee was deze te maken omdat ik graag een verwijzig maak, via wie wie elkaar kent. Bijv. Iemand is doorverwezen door iemand anders.

Waar het hélemaal misliep...
De formulieren zoals ik ze (voorlopig) in mijn dromen graag zie...
Wens ik een bestelling in te voeren. Klik ik ergens... nieuwe bestelling of niuwe Klant, formulier opent zich... (gaat misschien te ver?)

• Het formulier van de bestelling dus. Kan ik de naam van de contactpersoon selecteren die de bestelling maakt, aanuiden welke producten deze besteld. (kan minimum 10 producten toevoegen), natuurlijk kan hij X keer eenzelfde product kiezen dus er moet ook nog een aantal bij...
• Een formulier waar ik een klant kan kiezen. Bijv. in keuzelijst. Wanneer ik deze te zien krijg, krijg ik ook metten welke bestellingen deze maakte. Ook bijv. welke contactpersonen deze heeft doorverwezen.

Alvast superdanks!!
j.

 

[dnties]

Zelfs al zou ik voldoende kennis van Access hebben om je te helpen voorzie ik dat deze discussiedraad nooit een einde gaat hebben, eenvoudigweg omdat er nog zo weinig is en de opbouw (hoogstwaarschijnlijk) ook te wensen overlaat.

Al over gedacht om een van de voorbeelden/templates/sjabloonbestanden van Access/Microsoft te gebruiken? Om van te leren qua database- en tabelopbouw, qua relaties tussen tabellen, normalisatie en het gebruik van Access ontwerpcomponenten. Heeft verder het voordeel dat helpers altijd het origineel kunnen downloaden om te zien wat de makers voor ogen stond en (daarmee) wat de verschillen zijn tussen jouw denkrichting en die van die makers (dus mogelijk kun je dan tips krijgen over de denkrichting).

Ik vond dit stappenplan als begeleiding daarbij nuttig. Richt zich op CRM, dus lijkt mij geschikt voor jouw doel(en).

Tijs.

 

[jok078]

Dank je voor de tips...

Wat ik neerschreef is ind. een hele boterham! Het zou als een samenvatting van de gewenste acces toepassing kunnen beschouwd worden. Echter zie ik dit belangrijk om er stap voor stap naar toe te groeien. Beginnen doe je met de relaties... (naar mijn inzien staan deze op punt, of toch?) Zelfs zie ik ze hier of daar nog uit te diepen, maar dat is niet aan de orde. Via de postcode kan je de woonplaats acherhalen hé

Ik heb reeds de kennis van gevolgde opleidingen Acces en VBA (zelfs puur VB, al zit dat ver), welke ik volgde. Ik beken echter dat het ook weer even terug in de tijd gaat...
Ook, moet gezegd dat ik er niet dag-in dag-uit mee bezig ben, het zit me wellicht heel wat minder in de vingers (geen routine) als bij vele anderen...

Naar mijn inzien staat de structuur van de tabellen er echter wel. Achterliggende relaties, opbouw ervan. (waar kan je ID's in stoppen en waar niet, wat is onderliggend aan wat,...) Ik zeg echter zéker niet dat er fouten in staan! Ik vrees er namelijk voor!! Vandaar mijn hulp-vraag...
Hoe ik een formulier in elkaar kan boxen met hierin de keuzelijst van Klanten zie ik ook nog helemaal zitten (werk perfect), echter om hieronder alle producten weer te geven die ze ooit kochten is voor mij nog een zoektocht??

Het gebruik van voorbeelden, templates of sjabloonbestanden is me niet bekend. Ga ik zeker verder uitzoeken. Het gebruik van de wizzards binnen acces is zeker een vaak gebruikt iets, waarmee je met enkele muisklikken je basis formulier kan opbouwen is me wel bekend en vaak gebruikt. Van hieruit maak ik m'n formulier verder op. Echter lijkt me het hoofdstuk formulieren nog niet aan de orde, gezien ik nog niet zeker ben van de opbouw van de relaties tussen de tabellen. Vandaar mijn hulpvraag.

With a little bit training, I'm just a Ferrary... sticker welke ik me herinner... plakje op een klein autotje van begeleidster in revaliatiecentrum...:thumb: (betreft voor mij een heel bijzondere herinnering, please be respectfully)
jo

 

[OctaFish]

Laten we beginnen (in tegenstelling tot dnties weet ik wél een heleboel af van databases) met de grootste denkfouten er uit te vissen. Als die weg zijn, wordt de te volgen weg vanzelf duidelijker)...

Beginnen doe je met de relaties... (naar mijn inzien staan deze op punt, of toch?) Zelfs zie ik ze hier of daar nog uit te diepen, maar dat is niet aan de orde.

Nee, je begint níet met relaties. Je begint met het bedenken van een functioneel ontwerp: wat wil ik kunnen doen met de database, en wat heb ik daar voor nodig? Als ik je db bekijk, en je verhaal lees, dan wil je dus klanten registreren, en die klanten wil je enquetes kunnen opsturen. De antwoorden daarvan wil je registreren. Dat ziet er acceptabel uit, voorlopig. Beetje rudimentair, maar nog geen grote fouten gezien. Vervolgens wil je bestellingen kunnen plaatsen voor de klanten. En daar gaat het goed fout. Je schrijft bijvoorbeeld:

(kan minimum 10 producten toevoegen), natuurlijk kan hij X keer eenzelfde product kiezen dus er moet ook nog een aantal bij...

Je bedoelt waarschijnlijk maximum 10 producten, maar dat is semantiek, daar vallen we niet over. Je geeft zelf al een ongelooflijk groot probleem aan: op het moment dat een klant meer dan 10 artikelen wil bestellen, past het niet meer in de tabel. En moet je de tabel aanpassen. Nou, dat mag natuurlijk nooit het geval zijn. Toen ik je relaties zag (bekijk ik altijd als eerste) zag ik de 'fout' al direct, maar met voorbehoud: op het moment dat er altijd maar één artikel besteld kan/mag worden, mankeert er namelijk niks aan je opzet. Het deugt pas niet op het moment dat je meer artikelen mag bestellen. Op dat moment heb je een systeem nodig waarin je een onbeperkt aantal artikelen kan bestellen.
Dat doe je dan door een extra tabel te maken (BestelRegels bijvoorbeeld) waarin je het Bestelnummer opneemt en alle relevante artikelgegevens, zoals artikelnummer, prijs en aantal.

En dat is dus op dit moment het grootste probleem in je opzet. Maar het échte probleem is volgens mij dat je gelijk met het bouwen bent begonnen, en het nadenken over de opzet even op een lager plan hebt gezet .

 

[OctaFish]

Ik zat trouwens nog even naar je enquetes te kijken, en die constructie is bij nader inzien toch ook fout . Je legt de relaties precies verkeerd om namelijk, in je huidige constructie kun je per klant maar één enquete invullen, en je wilt er meerdere invullen. De relatie moet dus de andere kant op lopen. Maar dat kun je zelf wel aanpassen denk ik.

 

[jok078]

Zoals gedacht... Hrmm, ik had al wel een voorgevoel dat de vertaling van mijn concept (wat +/- neergeschreven is) naar de database (relaties) wel hier of daar fouten bevatte.
Moest het simpel zijn, was ik hier niet - lol

Ga het nog korter, krachtiger trachtten neer te schrijven.

Een klant met al zijn gegevens kan in één bestelling oneindig veel (hoeft geen limiet op te zitten) producten toevoegen (deze hebben telkens een aantal)
Een klant kan (op andere data) ook telkens een nieuwe bestelling doen. Later willen ik deze zichtbaar maken per klant, onder elkaar. (voor later!)
Toen ik dit aanvankelijk bedacht (zie mijn voorbeeld) zag ik mij beperkt tot tien (in het voorbeeld slechts 1), door product01, product02 enz. in de tabel van klant te verwerken. Ik voelde al wel dat er hier een beperking was, maar zie niet goed hoe ik het kan vereenvoudigen. Iemand een idee?? Hoe kan ik in mijn tabel TBL_bestelling steeds nieuwe producten toevoegen met hun aantal... - ik heb 'm niet...
Hoe kan ik dit anders oplossen? Kort (tracht mezelf te begrijpen) Een bestelling heeft maar één klant (via keuzelijst), maar heeft meerdere producten (via keuzelijst), die zichzelf aanvult???

Soort gelijk probleem... Hoe kan ik verwezelijken dat een klant meerdere contacten heeft... Een klant moet zijn contacten namelijk terugvinden in de lijst contacten - lol - exclusief zichzelf. Nog even nadenken (daar zal vb voor nodig zijn) hoe gaan we dat oplossen?

Laat ons probleem per proleem oplossen

Ik zie veel bos, weinig bomen... (komt wel goed...) :d
Rome en Parijs - ook niet in één dag...

 

[OctaFish]

OK, lezen is ook een kunst, blijkt uit deze opmerking:

Ik voelde al wel dat er hier een beperking was, maar zie niet goed hoe ik het kan vereenvoudigen. Iemand een idee?? Hoe kan ik in mijn tabel TBL_bestelling steeds nieuwe producten toevoegen met hun aantal... - ik heb 'm niet... Hoe kan ik dit anders oplossen? Kort (tracht mezelf te begrijpen) Een bestelling heeft maar één klant (via keuzelijst), maar heeft meerdere producten (via keuzelijst), die zichzelf aanvult???

Want het antwoord had ik al lang en breed gegeven in bericht #4:

Dat doe je dan door een extra tabel te maken (BestelRegels bijvoorbeeld) waarin je het Bestelnummer opneemt en alle relevante artikelgegevens, zoals artikelnummer, prijs en aantal.

Dus: goed antwoorden lezen, en probeer te snappen wat er staat . Overigens zie ik een heel ander probleem erbij komen, wat inderdaad wel degelijk beschreven hoort te zijn in een Functioneel Ontwerp (ik zal het verder FO noemen).

Een klant kan (op andere data) ook telkens een nieuwe bestelling doen.

Dat is, database technisch gezien, een klein probleem. Oplosbaar, maar toch. De vraag is ook: waarom? Je snijdt namelijk m.i. jezelf in de vingers, en jaagt tegelijkertijd de klant weg. En waarom zou je dat doen? Ik pak er even een voorbeeld bij van een online shop. Stel dat ik daar vandaag een nieuwe camera bestel. Prima, geen punt, camera besteld en betaald. Nu bedenk ik me: eigenlijk wil ik ook nog wat extra geheugenkaartjes hebben, en een harde schijf met WIFI zodat ik op lokatie de foto's over kan zetten. Jammer dan! Gaat niet lukken (in jouw winkel) want ik heb vandaag al een bestelling geplaatst! Wat denk je dat ik doe: tot morgen wachten voor de nieuwe bestelling, of een andere webwinkel zoeken?

 

[jok078]

Ik heb de database een helemaal herwerkt... Vooral de relaties dan.
Hoe ik nu een klant (zie database) in een bestelling meerdere orders kan laten maken, met hierin een hoeveelheid van één product. Ik heb geen idee hoe ik ze praktisch in een formulier werkend krijg.

Ik puzzel verder, maar ik denk dat een ervaringsdeskundige welkom is

Is er iemand die de relaties op orde kan brengen. Zonder dat (is mijn ervaring) is er geen verder werken aan.

Vast danks!
Jo

 

[OctaFish]

Ook dat heb ik al eerder gezegd: (je) relaties zijn het probleem niet. Een relatie in een (Access) database is alleen maar een middel om te voorkomen dat je niet-gerelateerde gegevens op kan slaan in een tabel. Zoals: in de tabel [Bestellingen] een bestelling opnemen van een niet-bestaande klant. Of, als je een postcode tabel hebt, een niet-bestaand adres invoeren in een klantentabel. Maar een goede database zonder één enkele relatie kan vele malen beter werken als een slechte database die stikt van de relaties.
Bedenk, voordat je überhaupt aan tabellen ontwerpen gaat denken (over formulieren heb ik het uiteraard nog helemaal niet), dus eerst goed voor jezelf wat je nu precies wilt. Zo heb je in je laatste bericht niet gereageerd op mijn opmerkingen over het mogen plaatsen van één bestelling per dag. Ik zie daar het bedrijfsmatige voordeel (voor jou noch klant) niet van. Toch wil je het inbouwen.... Daar moet dus een reden voor zijn, en die reden moet je in het FO terug kunnen vinden.