Between function for dates in Docmd.OpenReport rptName,,[date-filed] BETWEEN #date1# AND #date2# .. NOT WORKING

Question

Please assist, this is a nightmare indeed.
Am trying to filter records in a report using the BETWEEN function, as below:
strCondition = "Format([tblOrderLineTrack_main].[dtAllocation],'dd/MM/yyyy') BETWEEN Format(#06/02/2015#,'dd/MM/yyyy') AND Format(#07/03/2015#,'dd/MM/yyyy')" 
DoCmd.OpenReport strDocName, acViewPreview, , strCondition, acWindowNormal
The report is bringing up all records including those outside the specified range. What could be wrong with this???? Please assist, I am going nuts over this...

Answer 1

The date literals I used are in the
ISO standard for date notation of YYYY-MM-DD so are internationally unambiguous.  The only circumstance I can envisage in which it would not return the rows expected would be the extremely unlikely one where all the rows with dates in the range happen
to have a date of 7 March 2015, and all have a non-zero time of day element.  There is no such thing in Access as a date value, only a date/time value so #2015-03-07# in fact represents the point of time at midnight at the start of 7 March 2015. 
Any rows with date/time values of that date, but with a non-zero time of day would consequently fall outside the range.
The above is so unlikely that I can't believe it to be the case, but the bullet-proof syntax would be:
    strCondition = "dtAllocation  >= #2015-02-06# " & _
          "AND dtAllocation < #2015-03-07#+1"
i.e. all date/time values on or later than the start of the first day of the range (#2015-02-06 00:00:00#) and before the start of the day following the end of the range (#2015-03-08 00:00:00#)
Assuming that the dtAllocation column is of date/time data type, and is returned as such in the report's RecordSource, not as a formatted string expression, I can see no reason on the information available why the above should not work, so if the report is
still not returning any data some other reason not apparent to us must be suspected.  We are not in a position to debug the report, however, so what that might be I can't say.
Ken Sheridan, Stafford, England