B
Bonaldi
I have a table with a daily log of info called (big surprise here)
Daily_Log and I have filled it with every date starting last November
until way into 2012
On each record (with the Date as the key field) I have a byte field
with a 1 indicating that a given organisation is trading on that day
and a 0 if not. (i.e. I initialised all the values with 1's and then
zeroed out the weekends and public holidays.)
So, to find out how many "trading" days have occurred between a
"start" and "end" date all I have to do is invoke a dsum of this field
filtering the records between the given dates.
So far, so simple.
IMPORTANT - I am based in the UK and my windows setting reflects this
and Access USUALLY responds accordingly.
i.e. In the UK we write dates in ascending order. Hence, if I set the
format on a text control to "medium date" and enter 01/02/11 Access
will show me "01-Feb-2011" (as opposed to the US version 02-Jan-2011.)
(I stress the "USUALLY" because I have found exceptions to this before
and strongly expect that I am in the same territory again - though I
can't see where!)
Now on my opening menu FORM I want to show the number of trading dates
that have occurred since the first of that month.
Hence I have txtTrading_Date = Date() to give me
today's date
txtMonth_Start_Date =
DateSerial(Year(Date()), Month(Date()), 1) to give me the full date
of the first of the month. These work perfectly.
and the computed number of trading days as:
DSum("[DL_Open]","Daily_Log","[DL_Date] between
[txtMonth_Start_Date] and [txtTrading_Date]")
This also works perfectly.
But within a query! I am getting ready to shoot someone - or myself.
I want to run an update query down a set of records with fields
Start_Date and End_Date to enter the appropriate value into the field
"Duration".
I use exactly the same dsum as before (obviously substituting the
field names for the form's txt controls) but it just does not want to
know.
I have tried every combination I can imagine to try and make this work
- obviously testing as a select query first to see the answer before
applying it to an update.
I even try a simplified version (albeit providing the wrong answer,
but anything to get the ball rolling!) of simply counting every value
greater than the start date (rather than a "between" test.)
Imagining that it was having a problem reconciling some kind of UK v
US date thing (which there shouldn't be because this is an Access
query operating on an Access table where Access has total control of
how it stores - end hence reads back - it's own internal date
structure) I even inseted the DateSerial reconstruction of the
deconstructed parts of the date field. A long road round, for sure,
but as long as it works.
Yeah - but it doesn't. Still no difference.
Always the same result - 303, which just happens to be the sum of all
the 1s in that field in the Daily_Log table.
i.e. It ignores any attempt to filter anything out and allows every
record from the Daily_Log through to be summed.
I would be deliriously happy to receive any pointers towards a
solution. I am really stuck on my project until I get over this
obstacle!
And a very happy new year to allow who even took the trouble to read
this far!
RD
Daily_Log and I have filled it with every date starting last November
until way into 2012
On each record (with the Date as the key field) I have a byte field
with a 1 indicating that a given organisation is trading on that day
and a 0 if not. (i.e. I initialised all the values with 1's and then
zeroed out the weekends and public holidays.)
So, to find out how many "trading" days have occurred between a
"start" and "end" date all I have to do is invoke a dsum of this field
filtering the records between the given dates.
So far, so simple.
IMPORTANT - I am based in the UK and my windows setting reflects this
and Access USUALLY responds accordingly.
i.e. In the UK we write dates in ascending order. Hence, if I set the
format on a text control to "medium date" and enter 01/02/11 Access
will show me "01-Feb-2011" (as opposed to the US version 02-Jan-2011.)
(I stress the "USUALLY" because I have found exceptions to this before
and strongly expect that I am in the same territory again - though I
can't see where!)
Now on my opening menu FORM I want to show the number of trading dates
that have occurred since the first of that month.
Hence I have txtTrading_Date = Date() to give me
today's date
txtMonth_Start_Date =
DateSerial(Year(Date()), Month(Date()), 1) to give me the full date
of the first of the month. These work perfectly.
and the computed number of trading days as:
DSum("[DL_Open]","Daily_Log","[DL_Date] between
[txtMonth_Start_Date] and [txtTrading_Date]")
This also works perfectly.
But within a query! I am getting ready to shoot someone - or myself.
I want to run an update query down a set of records with fields
Start_Date and End_Date to enter the appropriate value into the field
"Duration".
I use exactly the same dsum as before (obviously substituting the
field names for the form's txt controls) but it just does not want to
know.
I have tried every combination I can imagine to try and make this work
- obviously testing as a select query first to see the answer before
applying it to an update.
I even try a simplified version (albeit providing the wrong answer,
but anything to get the ball rolling!) of simply counting every value
greater than the start date (rather than a "between" test.)
Imagining that it was having a problem reconciling some kind of UK v
US date thing (which there shouldn't be because this is an Access
query operating on an Access table where Access has total control of
how it stores - end hence reads back - it's own internal date
structure) I even inseted the DateSerial reconstruction of the
deconstructed parts of the date field. A long road round, for sure,
but as long as it works.
Yeah - but it doesn't. Still no difference.
Always the same result - 303, which just happens to be the sum of all
the 1s in that field in the Daily_Log table.
i.e. It ignores any attempt to filter anything out and allows every
record from the Daily_Log through to be summed.
I would be deliriously happy to receive any pointers towards a
solution. I am really stuck on my project until I get over this
obstacle!
And a very happy new year to allow who even took the trouble to read
this far!
RD