Results 1 to 12 of 12

Thread: Rekenen met db velden

  1. #1

    Rekenen met db velden

    Hallo,

    Ik schrijf een programma dat zal gebruikt worden bij een etentje van een school.

    De secretaris moet van alle drank en voedsel de eenheden ingeven (vb : 1 x cola, 2 x taart ....)
    Zie afbeelding

    Click image for larger version. 

Name:	delphi_rekening.PNG 
Views:	140 
Size:	38.9 KB 
ID:	7646

    Nu wil ik na elke ingave dat het totaal aangepast wordt.
    De ingave wordt pas bewaard na het ingeven van alle velden.

    Ik zou een functie maken die na een onchange event wordt opgeroepen.
    Maar hoe kan ik alle DBEdit velden overlopen en vermenigvuldigen met de overeenkomstige prijs.

    Hoe kan ik dit het beste verwezelijken?

    Bedoeling is dat het getal 52 automatisch wordt gegenereerd. Hier heb ik het gewoon ingevuld. (De prijs van de cocktail is verkeerd, never mind :-) )

    Click image for larger version. 

Name:	delphi_rekening1.PNG 
Views:	113 
Size:	23.2 KB 
ID:	7647

    Alvast bedankt

    Lainkes

  2. #2
    Je kunt in een dataset gebruik maken van calculated fields en voor het totaal zou je in een while loop door de dataset heen kunnen lopen voor het totaal. Het hangt er wel van je ontwerp af of dit mogelijk is.

  3. #3
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Of gebruik maken van componentcount. Al is het met calculated field makkelijker, omdat je format naar double al gemaakt is.
    voor componentcount zal het zoiets worden:
    Delphi Code:
    1. function tform1.calculate : double;
    2. var index : integer;
    3. begin
    4.   result := 0.00;
    5.   for index := 0 to componentcount -1 do
    6.   begin
    7.     if component[index] = TDBEdit then  //ander classcomponent mag ook
    8.        result := result + strtofloat(TDBEdit(component[index]).text)
    9.   end;
    10. end;
    Delphi is great. Lazarus is more powerfull

  4. #4
    @JKuiper

    Volgens mij ben je de prijs vergeten mee te nemen

  5. #5
    En tevens even opletten dat je de TotaalDBEdit niet per ongeluk meeneemt met tellen

  6. #6
    OK, bedankt. Ik ga dit proberen.

    Ook wil ik op het einde van de dag een overzicht van het toataal van elk item.
    Moet ik dan voor elk item een variabele aanmaken, en dan met een sql-query (sum(fieldname)) deze opvullen?
    Of kan dit eventueel in een loop? Dit zou eenvoudiger zijn als er later items bijkomen.

    Bedankt

    Lainkes

  7. #7
    Is dit iets dat je per keer "aanslaat" en dan weer op nul begint?

    Verder hangt het (zoals al eerder gezegd) ook een beetje af van hoe jij je items in de database opslaat.
    Als je alles velden in 1 tabel gooit is dat niet echt flexibel.
    Eigenlijk moet je dus een soort tabel hebben als:
    SQL Code:
    1. CREATE TABLE KOSTEN
    2. (
    3.   ITEM_ID     BIGINT,
    4.   AFREKEN_ID  BIGINT,
    5.   DATUMTIJD   TIMESTAMP,
    6.   L_SOORT     BIGINT NOT NULL,
    7.   AANTAL      INTEGER,
    8.   PRIJS       NUMERIC(18, 2) DEFAULT 0.00 NOT NULL,
    9.   TOTAAL      NUMERIC(18, 2) DEFAULT 0.00 NOT NULL
    10. )
    ITEM_ID is dan een autoincrement per opgeslagen item.
    AFREKEN_ID is een ID voor die rekening (meerdere items).
    L_SOORT is een link naar een drank- en voedseltabel SOORT.
    AANTAL en PRIJS is voor dat item.
    en TOTAALPRIJS is totaalbedrag voor dat item.

    Een afreken-bon bestaat dus uit meerdere van deze items.

    Deze vorm kun je echter niet met een simpel aantal DBEdits oplossen. Je zult dan eerst aan de hand van je voedsel-tabel SOORT alle TEdits op het scherm kunnen zetten (e.v. opgedeeld in verschillende TGroupBoxen afhankelijk van soort voedsel). Dit scherm bouw je dan in code op. Het voordeel daarvan is dat als je een soort drank of voedsel erbij wil zetten je alleen maar de voedsel-tabel SOORT aan hoeft te passen.

    Als er dan op een Afreken-knop gedrukt wordt dan loop je al die TEdits af om de waardes daarvan (indien ingevuld) op te slaan in de KOSTEN-tabel.

    Ik weet alleen niet of je een beetje begrijpt hoe ik het hier boven uitleg.

    Het is wat ingewikkelder dan 1 record voor ALLE voedselsoorten (met allemaal velden) maar vele malen flexibeler indien je iets gaat wijzigen in prijs en soort drank/voedsel.

  8. #8
    Ik heb inderdaad alle items in 1 record.
    En zal dus alle records moeten aflopen om de totalen te verkrijgen.

  9. #9
    En waar staat de prijs voor die items?

    En wat als de secretaris besluit een nieuw drankje te introduceren of de prijs van de bitterballen te verhogen?

  10. #10
    De items staan in een aparte tabel. De prijs kan aangepast worden in een andere form, waar de prijs van alle items editeerbaar zijn. Nieuwe toevoegen is idd een probleem.

  11. #11
    Staan die items dan ook in 1 record of heb je daar wel allemaal verschillende records voor?

    Zoiets?
    SQL Code:
    1. CREATE TABLE ITEMS
    2. (
    3.   ITEM_ID     BIGINT,
    4.   NAAM        VARCHAR(50),
    5.   SOORT_ID    BIGINT,       /* voor welke TGroupBox */
    6.   SOORT       VARCHAR(50),  /* GroupBoxnaam b.v. Drank, Schotels, Snacks, Diversen */
    7.   VOLGORDE    BIGINT,       /* volgorde in die groupbox */
    8.   PRIJS       NUMERIC(18, 2) DEFAULT 0.00 NOT NULL
    9. )
    Want als je ze al op deze manier in een tabel hebt staan dan zou je je invoerscherm het beste dynamisch in code op kunnen bouwen. Dan is het wijzigen van de tabel ITEMS voldoende om dat scherm ook helemaal aan te passen. Je kunt TEdit.Tag gebruiken om ITEM_ID op te slaan. Daarna kun je die TEdit.Tag gebruiken als herkenning dat je iets moet tellen en ook op te slaan in de database.

    Toevoegingen en wijzigingen zijn dan een fluitje van een cent.

  12. #12
    Jup. 1 schermpje om artikelen en hun prijs te bewerken. Een ander schermpje om artikelen af te boeken. Door je scherm dynamisch op te bouwen kan je voor elk artikel een knop genereren. En eigenlijk heb je dan al een simpel kassasysteempje gebouwd.

    Voor het afrekenen druk je op een knop om artikelen en hun prijs toe te voegen aan een transactie. Die artikelen kan je afzonderlijk in een dataset opslaan. In een TClientDataSet kan dat eenvoudig. Je kan in zo'n dataset ook een calculated field maken waarin prijs*aantal per regel wordt uitgerekend. Een ander type veld zijn 'aggregates' die weer het totaal van de hele dataset voor je kunnen uitrekenen. Dat aggregate veld koppel je aan de edit waarin je het totaal toont. Dat kan je allemaal inrichten zonder een regel code te schrijven. (Vergeet niet de knoppen om een artikel uit de transactie te verwijderen of de hele transactie te annuleren).

    Bij het bevestigen kan je de transactie en de artikelen wegschrijven in twee tabelletjes. Bij de transactie leg je eventueel het tijdstip vast, en bij de artikelen de prijs. Ze zijn dan tenslotte al betaald, en je wilt de oorspronkelijke prijs weten als je de prijs van een artikel aanpast.

    Wanneer moest het af zijn? En waar is dat feestje?
    1+1=b

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •