Results 1 to 11 of 11

Thread: Firebird update Boekdatum > 01-01-2020

  1. #1
    Senior Member
    Join Date
    Jan 2009
    Location
    Alkmaar
    Posts
    488

    Firebird update Boekdatum > 01-01-2020

    Het zalwel weer iets heel simpels zijn, maar ondanks veel spitten en proberen kom ik er niet uit.
    Wat ik wil is een query die bepaalde kolommen (col1,col2 enz) Null maakt voor elke Boekdatum vanaf 01-01-2020.
    Al geprobeerd met cast enz. maar het wil maar niet lukken !

  2. #2
    SQL Code:
    1. UPDATE TABLE
    2. SET col1=NULL, col2=NULL
    3. WHERE boekdatum>='2020-01-01'

  3. #3
    Senior Member
    Join Date
    Jan 2009
    Location
    Alkmaar
    Posts
    488
    Bedankt Rik,

    ik had dat inderdaad ook al geprobeerd, maar dacht dat het niet werkte omdat ik zo stom was om de table te bekijken zonder naar het einde te gaan, waar juist de mutaties zichtbaar moesten zijn !
    Overigens werkt het tot mijn verbazing zowel met '2020-01-01' als met '01-01-2020'. Kennelijk maakt het voor Delphi niet uit welke notatie je gebruikt !

  4. #4
    Quote Originally Posted by riverrat View Post
    Overigens werkt het tot mijn verbazing zowel met '2020-01-01' als met '01-01-2020'. Kennelijk maakt het voor Delphi niet uit welke notatie je gebruikt !
    Ja, maar dan moet je heel erg goed opletten als je '04-10-2020' gebruikt. Want dat zou best eens 10 april kunnen zijn in plaats van 4 oktober.
    Vandaar dat het ALTIJD beter is de ISO notitie te gebruiken YYYY-MM-DD.

  5. #5
    Senior Member
    Join Date
    Jan 2009
    Location
    Alkmaar
    Posts
    488
    Als ik weer eens tijd over heb ga ik dat toch eens proberen, maar het valt me al mee dat het niet uit schijnt te maken of je het jaar eerst of laatst zet !

    Even geprobeerd : '01-30-2020' geeft conversie foutmelding, maar '30-01-2020' ( dus de normale Nederlandse manier) werkt goed ! Jaar verplaatsen mag dus wel, maar dag/maand wisselen niet !
    Last edited by riverrat; 04-Jun-20 at 15:49.

  6. #6
    Quote Originally Posted by riverrat View Post
    Even geprobeerd : '01-30-2020' geeft conversie foutmelding, maar '30-01-2020' ( dus de normale Nederlandse manier) werkt goed ! Jaar verplaatsen mag dus wel, maar dag/maand wisselen niet !
    Dat kan dus ook afhangen van de "locale" van de machine waarop de database engine draait (of die van de Client).
    Als die bijvoorbeeld op een Windows machine draait die op Engels staat, dan zal '30-01-2020' weer de conversie error geven.

    Vandaar dat het gewoon het allerbeste is.... als je te maken hebt met opslag in de database, ALTIJD YYYY-MM-DD gebruiken.

  7. #7
    Niet elke tool gaat ook op dezelfde manier om met datums.

    Zelf doe ik voor een harde actie zoals die van Riverrat ook altijd eerst een select om zeker te weten dat ik de goede resultset krijg op basis van die where.

  8. #8
    Quote Originally Posted by Benno View Post
    Niet elke tool gaat ook op dezelfde manier om met datums.
    Gelukkig ben ik nog geen tool tegengekomen die niet om kan gaan met YYYY-DD-MM.

    Zelf doe ik voor een harde actie zoals die van Riverrat ook altijd eerst een select om zeker te weten dat ik de goede resultset krijg op basis van die where.
    Hoe doe je dat?
    Als je op 01-01-2020 begint met een database, dan kom je er op 13-01-2020 pas achter wat de werkelijke datumnotitie is. Voor een eerste record die jij dan op 13-01-2020 opslaat, kan dat dus nét de verkeerde notitie zijn.

    En als je op 05-06-2020 een select doet... dan moet je dus een hele dataset afzoeken naar een datum die dus de ene of andere notitie kan zijn.

  9. #9
    Gelukkig ben ik nog geen tool tegengekomen die niet om kan gaan met YYYY-DD-MM.
    Je hebt weer eens gelijk ... Ik zat altijd met datums te hannesen in bv Flamerobin die dd.mm.yyyy wil zien. Maar inderdaad werkt YYYY-MM-DD ook. Weer wat geleerd.

    Hoe doe je dat?
    Als je op 01-01-2020 begint met een database, dan kom je er op 13-01-2020 pas achter wat de werkelijke datumnotitie is. Voor een eerste record die jij dan op 13-01-2020 opslaat, kan dat dus nét de verkeerde notitie zijn.

    En als je op 05-06-2020 een select doet... dan moet je dus een hele dataset afzoeken naar een datum die dus de ene of andere notitie kan zijn.
    IK begrijp niet zo goed wat jij hier bedoeld.

    Mijn reactie was meer op de vraag van Riverrat en jouw oplossing. Ik zou dus zelf altijd een select * doen met die where om te zien of ik daar geen gekke dingen ga krijgen. Pas dan zou ik de update of delete doen. Uiteraard kun je niet alle regels gaan controleren, maar door even te scrollen kun je snel zat zien of je (waarschijnlijk) de juiste set hebt.

    Jij hebt waarschijnlijk wat meer vertrouwen in je sql skills en tools dan ik

  10. #10
    Quote Originally Posted by Benno View Post
    Ik zou dus zelf altijd een select * doen met die where om te zien of ik daar geen gekke dingen ga krijgen.
    Als je dataset nog niet zo groot is en je met SELECT * alleen maar records krijgt waar dag < 13, dan weet je nog niets.
    (dat bedoelde ik eigenlijk)

    Result:
    03-04-2020
    06-08-2020
    02-06-2020

    Dus dan weet je in het begin van het gebruik van je programma niet hoe de datumvorm is.
    Dat kan tot problemen leiden

    Maar misschien zou je, als je rekening houdt met een ORDER BY DATUMVELD wel al iets sneller kunnen detecteren welk veld de dag is (door te kijken welke velden oplopen). Maand 02 komt dan niet na maand 03. Maar helemaal 100% proof is deze oplossing ook niet.

  11. #11
    FireBird (her)kent een aantal datumformats. Gebruik je een ander format dat zal de string omgezet worden, en daarbij zal inderdaad gebruik gemaakt worden van de instellingen van de sessie, die weer zijn afgeleid van het OS van de client.

    Ter vergelijking, Oracle kan ook allerlei conversies doen, maar understeunt ook een specifiek date format (eveneens 'yyyy-mm-dd') dat vooraf gegaan wordt door het keyword `date`. Bijvoorbeeld date '2020-06-04'. Het voordeel van deze notatie is inderdaad dat het alle ambiguiteit weghaalt over of 04 of 06 de datum is, want niemands bij z'n volle verstand gebruikt 'yyyy-dd-mm' als format.

    Zie Firebird Date Literals voor wat uitleg en opsomming van de ondersteunde formats. `dd-mm-yyyy` staat niet in het lijstje..
    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
  •