Many folks misunderstand the "w" interval setting used in the DateDiff() expression. The MS Access help file indicates that this interval is for "Weekdays". To some the term "Weekdays" means "Workdays" (ie: Monday through Friday), thus the confusion and claim that the "w" interval does not work. But the term "Weekdays" (thus the interval "w") means an indicated day of the week.
o ... with an expression like:
DateDiff("w", #4/1/2008#, #4/30/2008#)
The returned result is 4. Access looks at the start date of the indicated span and determines the day of the week the start date falls on, which is Tuesday in this case. Access will then count the number of Tuesdays between the dates indicated, note that the start date is NOT included in the count.
Other samples:
DateDiff("w", #4/2/2008#, #4/30/2008#)
-- returns 4 (the number of Wednesdays between the two dates)
DateDiff("w", #4/3/2008#, #4/16/2008#)
-- returns 1 (the number of Thursdays between the two dates)
{As a side note, the similar interval "ww" simply returns the number of Sundays between a date span.}
.....
Knowing how the "w" interval works can be quite handy when doing date calculations ...
For example, here are two archive posts that utilize the "w" interval of DateDiff():
fNetWorkdays() and fAddWorkdays()
fCountWeekdays()
Orealize that this little bit of information is touched on in the Access help file on the DateDiff() function, but with the confusion that is often associated around the "w" interval, I thought it was worth expanding upon. I hope you have found this information helpful. thumbup.gif

Add a ListView control like the one in Dynamics AX. The control should NOT HAVE master/child field linking. Only needs an after-update event that triggers when the user clicks on a row, just like a ListBox.

Access ListBox is frequently used for form navigation. It’s easy to implement but has several serious drawbacks.

Its worst drawback is the form blinking that occurs when the AfterUpdate event is triggered. This makes your form functionality unprofessional.

Other drawbacks: It’s static, user can’t adjust column width or row height. Can’t be filtered or copied from.

The current work around is to use a datasheet subform that calls back to the parent form on its OnCurrent event. This is tedious programming, problematic and may not work at all if the parent datasource and subForm datasource have inherited back-end relationships.

Just like a combo but without a drop down button and does not allow editing. It would be bound to a FK but display a selected column from the related table but not be editable and would not have a drop down button.

This would save having to add related tables to a form's record source when you only want to display a column. And you definitely don't want to allow the user to modify it.

An example would be on a continuous form bound to tblInvoice, The control is bound to tblInvoice.CustomerID but displays tblCustomer.CustomerName.

This could possibly be achieved by adding a property to ComboBox to remove the button and lock it (but not disable it so a user can still select the displayed content if they need to copy it to the clipboard).

The Search box in the Navigation Bar at the bottom of forms is a pretty small area -- sometimes tiny, depending on the size of the form. And if you use a Navigation Caption, it's even smaller still.

When the user clicks in the Search box, it should auto-expand, making the scroll bars next to it temporarily shorter and the Search box longer, until the user is done with the search. Then it can go back to normal.

Alternatively, it could be replaced with a small pop-up that appears when the user clicks in it. But just increasing the size of the box should be sufficient.

The Access 2000 mdb format supports VBA UserForms with normal and parent controls, but all database formats beyond Access 2003 (ACCDB) only render UserForms that do not include Parent controls.

Being able to reuse UserForms across VBA hosts is a very useful way of reusing code and User Interfaces, but a runtime error (Error 75) occurs when trying to render a UserForm in an ACCDB database format, when there is a Parent control (such as a Frame or MultiPage control) present.

Parent controls enable rich functionality and more intuitive UI, but Access fails to render the forms, with an error that suggests that the VBA Project is corrupted.