>>>>>If you're using SQL 2012 and up and can guarantee that, then I suggest to try my version as simpler one.
>>>>
>>>>I can't be sure that the user won't be using 2008
>>>
>>>With datetime values you better use grater or equal than and less approach. With dates between is perfectly acceptable.
>>
>>Much of my work is with accounting applications, where in many cases the month and year, and not the day, are significant.
>>
>>In those cases, rather than prompting for a date, I prompt the user for the month and year and do my queries this way:
>>
>>

>>SELECT * FROM  view_expandedcoindrop WHERE MONTH(dropdate) = @rptmonth AND YEAR(dropdate) = @rptyear ORDER BY store,dropdate
>>
>>

>>
>>The users prefer that to having to enter "10/31/16" when the 31 is superflous and meaningless.
>>
>>I couldn't figure out a good way to get a range just using month and year.
>
>Just curious - when you look at the execution plan for that query, what do you get?
>
>Roughly how big is this invoice table? (# of rows)

Invoice table a couple of million rows.
The query typically returns a couple of dozen rows.
I do execution plans on an as-needed basis.
This query zipped right through.
If I reduced the execution time of this query by a factor of 1 million, the user would never know the difference.

See the recent VFP discussion where some really bright people dedicated a lot of ink to the subtle merits/demerits of the mdot.
I couldn't help musing that if I could have somehow miraculously marshalled all that brainpower for that period of time, I probably could have produced a pretty good, affordable, tax preparation sytem and the world needs a pretty good, affordable, tax preparation system

.