Results 1 to 9 of 9
  1. #1
    Join Date
    Sep 2007
    Posts
    3

    Post Unanswered: Calculate the DAYS since a certain date.

    Edit, title must read: "Calculate the DAYS since a certain date."

    Dear all,

    I'm working on a database to track goods. It is important that we know when the goods have arrived more than 45 days ago.
    So far I have not been able to do this.
    I have been looking at using DateDiff("d",ArrivalDate,CurrentDate) but I can't get the last date to change.

    any suggestions?
    Thnx!
    Last edited by gvee; 09-27-07 at 06:04. Reason: Thread title changed :)

  2. #2
    Join Date
    Apr 2005
    Location
    Zagreb - Croatia
    Posts
    372
    Try this;
    If [ArrivalDate] < DateAdd("d",-45,Date()) Then ...
    Last edited by MStef-ZG; 09-27-07 at 06:04.

  3. #3
    Join Date
    Sep 2007
    Posts
    3
    Thnx for your reply!

    I'll be a little more precise.
    We need to now how many days the goods are standing there. I meant witht the 45 days that we need to be able to see what goods are approaching the limit and and what goods are already over the limit.

    So first I want to now how many days they are standing. After that I can sort them and implement a querie.

    Thnx again!

  4. #4
    Join Date
    Apr 2005
    Location
    Zagreb - Croatia
    Posts
    372
    I think "DateDiff" function will work.
    Look at Attachment.
    Attached Files Attached Files

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    if you subtract 45 from the current date you will get your trigger date, ie anything before that trigger date is waht you want to look at


    datOrderCutoff = date()-45

    you can use that approach in a query

    eg
    select * from Orders where OrderDate< date()-45 and orderStatus=undelivered
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,424
    Provided Answers: 8
    I would change the

    <Date()-45 to <dateadd("d",-45,date())

    Its beater msaccess english
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  7. #7
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by myle
    I would change the

    <Date()-45 to <dateadd("d",-45,date())

    Its beater msaccess english
    I'll second this and explain why.

    A typical optimization strategy is what's known as "constant folding." If you've got a filter expression like [i]DateDiff("d", field, Date()) < 45[i], Access *probably* can't do anything with that expression. It's going to have to evaluate it separately for every row. (It could, in principle, rewrite the expression as the one myle suggested above, but I doubt it's smart enough to do the algebra.)

    If you write < DateAdd("d", -45, Date()), Access can see that Date() is constant for the query, and that DateAdd with three constant parameters must return a constant result. Then Access knows it's comparing a field to a constant value, and that operation can make use of an index.

    But I'm only speculating that Access does this. If you happen to have a few million records and can try both queries, let us know if one is consistently an order of magnitude faster.

  8. #8
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,424
    Provided Answers: 8
    Thanks ScoO8y

    You worded it heaps beater than i would of
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    sorry i remain to be convinced on that one

    I can see that you may be right if the date bracket was moving.. but by using date() we are using the current system date. I don't know, Im guessing, that the SQL parser will resolve that to a constant

    so I agree that using constants is better for the SQL parser to handle... it evaluates once,I don't see how

    where <myorderdate> < date()-45

    is significantly worse performance wise than

    where dateadd("d",-45,date())

    ..as effectively both statements resolve to constants.

    the only grey area I could see would be if the parser tested the date each iteration to see if the date had changed.. but both examples would have the problem, but the datediff variant would have to do more work (its making two calls to a function, one of which is a fairly complex generalised function), the other is a simple bit of memory retrieval and subtraction.

    in my very crude tests on a small data set.. around 150K rows there seemed to be no significant difference between the two variants, if anything the date()-45 seemed to occasionally come off better, but the difference was so small as to be meaningless, which suggests to me that parser is interpreting both statements as constants.
    I'd rather be riding on the Tiger 800 or the Norton

Posting Permissions

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