[Delphi] Field toevoegen aan database

[GENETX]

Laatst heb ik mezelf verdiept in het gebruiken van een database met delphi voor school en een projectje waar ik mee bezig ben. Nu zou het echter makkelijk zijn om een field toe te kunnen voegen aan een table binnen delphi voor dat project. GoT afgezocht, het internet langs, boek erbij gepakt, maar.... nergens een oplossing gevonden, in de zin van 1 die werkt voor mij...

Ik gebruik een MS-access database die ik dmv ADOTable in delphi bedien. Heeft iemand van jullie een oplossing, stukje code, voorbeeld oid waarmee ik dit voor elkaar zou kunnen krijgen? In ieder geval al bedankt!

[Spockz]

Is het niet het makkelijkst om gewoon een veld aan de databasetabel toe te voegen?

[RobIII]

Spockz schreef op zondag 01 juli 2007 @ 11:58:
Is het niet het makkelijkst om gewoon een veld aan de databasetabel toe te voegen?

...en anders met een ALTER TABLE statement.

[GENETX]

Zo ver reikt mijn kennis dus niet. Dat ALTER TABLE ben ik wel tegengekomen maar heb nergens een concreet voorbeeld/stuk code gezien waarmee ik uit de voeten kan dat het ook werkt. Een field aanmaken vanuit access is mn 2e optie, maar het is eigenlijk een hele slechte oplossing. Het gaat me er om dat ik vanuit het programma zelf automatisch bij het toevoegen van iets een field aanmaak vanuit het programma zelf dus.

Het project is het maken van een kassasysteem voor een restaurant van mn buurman. Het idee dat ik in mijn hoofd heb is als volgt:

Ieder product heeft zijn eigen ID, echter kunnen er later neiuwe producten worden toegevoegd. Nu wil men ook van oude kassabonnen kunnen zien wat er is besteld. Een optie om een max van 500 producten oid in te bouwen is er dus niet bij omdat deze dan zullen worden overgeschreven.

Het idee:

Bon | 1 | 2 | 3 |
---------------------
1 | 0 | 1 | 3 |
2 | 2 | 0 | 1 |

Toen kwamen er nieuwe producten (een maand later met nieuwe klanten). de fields zijn dus de producten waarbij de daaronder per bon wordt aangegeven hoeveel er is afgenomen.

Bon | 1 | 2 | 3 | 4 | 5 | 6 |
---------------------
1 | 0 | 1 | 3 | 0 | 0 | 0 |
2 | 2 | 0 | 1 | 0 | 0 | 0 |
3 | 0 | 1 | 2 | 0 | 1 | 3 |

Dus als iemand een stukje code heeft of een beter idee heeft, kom maar. Optie 2 is dus gewoon 500 fields aan te maken en wanneer ze bij die grens aankomen gewoon even in access nieuwe fields aanmaken, maarja dat is niet zo mooi eigenlijk.

[ Voor 8% gewijzigd door GENETX op 01-07-2007 12:12 ]

[RobIII]

GremliN-Online schreef op zondag 01 juli 2007 @ 12:11:
Zo ver reikt mijn kennis dus niet. Dat ALTER TABLE ben ik wel tegengekomen maar heb nergens een concreet voorbeeld/stuk code gezien waarmee ik uit de voeten kan dat het ook werkt.

Lijkt me erg sterk dat er niets op internet danwel in de help van Access te vinden is; ik geloof er dan ook niets van.

Daarnaast is je tabel ontwerp onzin; waarom gebruik je geen koppeltabel?

[ Voor 24% gewijzigd door RobIII op 01-07-2007 12:16 ]

[GENETX]

Er is dus wel wat te vinden, maar niet specifiek delphi code voor het component dat ik gebruik, of andere componenten die ik kan gebruiken. Iig heb ik een apar uur zitten zoeken en proberen, maar kreeg ik geen resultaat.. Het beste wat ik heb gekregen is dat hij geen error gaf

Zal even kijken RobIII, maar dat is dus niet een concreet stuk delphi code waar ik echt iets aan heb. Dit soort dingen had ik dus ook wel gevonden, maar niet direct met de uitleg met welke delphi componenten en hoe en zo wat. Vandaar dat ik het ook hier vroeg aangezien er wel een delphi mens zal rondhangen die een stukje code heeft dat ik wel begrijp.

[ Voor 38% gewijzigd door GENETX op 01-07-2007 12:17 ]

[Spockz]

Hmm, verbeter mij als ik je verkeerd begrijp maar voeg je nu voor elk nieuw product een field toe?

Je kan veel beter zoals RobIII zegt een productid opnemen in je tabel en die laten verwijzen naar een bepaalde row in je producten table met het relevante productid.

[RobIII]

GremliN-Online schreef op zondag 01 juli 2007 @ 12:14:
Zal even kijken RobIII, maar dat is dus niet een concreet stuk delphi code waar ik echt iets aan heb. Dit soort dingen had ik dus ook wel gevonden, maar niet direct met de uitleg met welke delphi componenten en hoe en zo wat. Vandaar dat ik het ook hier vroeg aangezien er wel een delphi mens zal rondhangen die een stukje code heeft dat ik wel begrijp.

We doen hier niet aan quickfixes. Je moet prima in staat zijn om met behulp van wat zoeken in documentatie en met de gegeven tips zelf tot een oplossing te komen; programmeren is niet de kunst van het bij elkaar sleuren-en-pleuren van componenten Daarnaast is (as said) je databaseontwerp onzinnig en zul je moeten kijken naar een koppeltabel; dat is basiskennis SQL en als je met DB's aan de slag wilt gaan zul je dus eerst moeten zorgen dat je ze (min of meer) onder de knie hebt. Mijn suggestie is dan ook (nog steeds): Neem eens een (fatsoenlijke) SQL tutorial door.

[GENETX]

Dat snap ik verder ook wel. Ik zal de FAQ nog even doorlezen. GoT was verder mn laatste hoop aangezien google me niet tot veel bruikbaars leide. De tutorial die ik had gevolgd voor databases was ook goed, amar miste ook dit stukje helaas. Iig bedankt voor je hulp.

Hmm, verbeter mij als ik je verkeerd begrijp maar voeg je nu voor elk nieuw product een field toe?

Je kan veel beter zoals RobIII zegt een productid opnemen in je tabel en die laten verwijzen naar een bepaalde row in je producten table met het relevante productid.

Het was de bedoeling dat ik een table met producten had waar dan records worden toegevoegd met dingen als de prijs, BTW ed. BVij de bonnen kunnen die dan als field worden aangemaakt zodat daar later te zien is hoeveel is afgenomen per product. Ik zou ze natuurlijk ook in een stringlist in een field kunnen stoppen, maar dat maakt het minder overzichtelijk. Ik heb wel meerdere opties maar dit leek met mijn beperkte kennis de mooiste optie.

[Spockz]

ehm. Het zou al een stuk beter zijn als je je databaseontwerp 90 graden zou draaien. Je maakt nu je table definition variabel in plaats van de vulling.

[GENETX]

En wat ga je dan doen met een nieuwe bon? Juist dan moet je daar een nieuw veld voor hebben, of zit ik nu onlogisch te denken voor een database ontwerp?

Het idee is dat beide "assen" worden uitgebreid en daartussen zoals in excel tabel te zien valt hoeveel van iets is verkocht (product id) aan wie (bon)

[RobIII]

GremliN-Online schreef op zondag 01 juli 2007 @ 12:41:
Het was de bedoeling dat ik een table met producten had waar dan records worden toegevoegd met dingen als de prijs, BTW ed. BVij de bonnen kunnen die dan als field worden aangemaakt zodat daar later te zien is hoeveel is afgenomen per product. Ik zou ze natuurlijk ook in een stringlist in een field kunnen stoppen, maar dat maakt het minder overzichtelijk. Ik heb wel meerdere opties maar dit leek met mijn beperkte kennis de mooiste optie.

Oei oei oei... echt, verdiep je nog even in de materie want dit gaat compleet de verkeerde kant op. Je moet (zoals eerder gezegd) een koppeltabel gebruiken. LeveringID, ArtikelID en Aantal (to keep it simple). Verdiep je eens in normaliseren

GremliN-Online schreef op zondag 01 juli 2007 @ 12:49:
En wat ga je dan doen met een nieuwe bon? Juist dan moet je daar een nieuw veld voor hebben, of zit ik nu onlogisch te denken voor een database ontwerp?

Nomaliseren is de key hier.

[ Voor 18% gewijzigd door RobIII op 01-07-2007 12:52 ]

[Verwijderd]

Denk 's goed na over je datamodel, on the fly velden toevoegen aan een tabel is geen optie.
Een simpel kassasysteem ontwerpen is geen rocket science: als basis heb je een tabel artikelen, een tabel boekingen (waarin je alle aangeslagen artikelen in opslaat), een tabel transacties (zeg maar de identificatie van het kassabonnetje die gekoppeld is aan de bijbehorende records in je boekingen tabel) en eventueel een tabel klanten wanneer je de transacties aan een bestaande klant wilt koppelen.

Je een beetje inlezen in simpel database ontwerp lijkt me geen slecht idee.
Dit heeft overigens helemaal niks met Delphi te maken...

[GENETX]

Zal me er dan even in verdiepen. Het is me nu iig wel gelukt om een field aan te maken. Misschien dat een frisse poging dan ook helpt. Ik bleek dus een ADOCommand component nodig te hebben waar ik die code in kan zetten en kan executen... Bedankt voor de hulp.

Het deel delphi had meer te maken met het feit dat er wel wat delphi code aan te pas komt en componenten. Een databse opzich niet nee.

[ Voor 20% gewijzigd door GENETX op 01-07-2007 12:58 ]

[Verwijderd]

Natuurlijk kun je een TADOCommand of een TADOQuery gebruiken om een extra veld aan te maken, maar dat WIL je helemaal niet!

[GENETX]

Nee dat snap ik nu. Maar hoe zou jij het aanpakken om per bon te kunnen kijken wat er is verkocht? Wat jij zei vond ik zelf dan weer vaagjes.

[Megamind]

Je hebt 3 tabellen:

Producten:
ProductID - Naam - Prijs

Bonnnen
BonID - Klant - Datum

BonProducten
UniqID - BonID - ProductID

En zo koppel je ze aan elkaar.

[GENETX]

Ja had het net ook zelf gevonden. Zal me nu meer verdiepen en wat proberen. Allemaal hartstikke bedankt voor de hulp en het moet me nu zelf wel weer lukken. Nogmaals bedankt.

[Verwijderd]

Beetje mosterd na de maaltijd, maar ik had 't al ingetikt...

code:

Tabel Artikelen:
    ID              identity/autoincrement veld, primary key
    PLU             integer, de PLU-code die je op de kassa intikt 
                    (kan ook je PK zijn, dan heb je het ID-veld niet nodig)
    Omschrijving    tekst die op je bonnetje komt    
    Prijs
    ...
    overige velden die bij 't artikel horen zoals BTW-code, grootboeknummer, medewerker, etc.
    
Tabel Boekingen:
    ID              identity/autoincrement veld, primary key
    Tijd            datetime veld, moment van aanslaan             
    TicketID        koppeling naar het ID veld in Tickets 
    ArtikelID       koppeling naar het ID veld in Artikelen 
    Aantal
    ...
    eventueel Prijs en Omschrijving wanneer deze af kan wijken van die in de Artikelen tabel
    
Tabel Tickets (kassabonnetjes)
    ID              identity/autoincrement veld, primary key
    BonNummer       (kun je ook als PK gebruiken, dan heb je het ID-veld niet nodig)
    KlantID         koppeling naar het ID veld in Klanten, 
                    mag ook NULL blijven bij directe verkoop
    ...
    wat je verder nog wil bewaren bij 't bonnetje. eventueel de betaalwijze,
    maar die zou ik zelf in de Boekingen tabel opnemen
    
Tabel Klanten
    ID              identity/autoincrement veld, primary key
    Naam
    Adres
    Woonplaats
    ...
    kortom, leef je uit :-)

[Alex Picard]

Megamind schreef op zondag 01 juli 2007 @ 13:51:
Je hebt 3 tabellen:

Producten:
ProductID - Naam - Prijs

Bonnnen
BonID - Klant - Datum

BonProducten
UniqID - BonID - ProductID

En zo koppel je ze aan elkaar.

Ik zou voorstellen om het volgende toe te voegen aan BonProducten:

• Prijs (de actuele prijs van het product op dat moment, prijs in de database kan immers veranderen)
• Aantal

[RobIII]

Alex Picard schreef op zondag 01 juli 2007 @ 14:23:
[...]

Ik zou voorstellen om het volgende toe te voegen aan BonProducten:

• Prijs (de actuele prijs van het product op dat moment, prijs in de database kan immers veranderen)
• Aantal

Zowieso is het verstandig alle gegevens die historisch bijgehouden moeten worden (zoals een omschrijving die in de loop der tijd net zo goed kan wijzigen als de prijs) in de "bon" tabel bij te houden. Als je naderhand nog eens een bon opnieuw moet reproduceren heb je geen geziemel. Het is dan wel wat redundant, maar het bespaart je een hoop ellende.

[GENETX]

Ja inderdaad, dat was ik ook al van plan. Nu ik dit principe ook ken wordt het idd ook een stuk beter. Nogmaals bedankt.