How to prevent a blank form when a list box return no data?

[Dany]

HI Everyone,
I am trying to create a simple form that contains three list boxes, each one is based on a query. For example, The first one has the row Source as follows:

Select Id, Emp_name
  From Tbl_Employee
 Where Hire_date < "01/01/2010"
 

The second and the Third list box are based on the same query but with different condition. Everything is good so far. But whenever the second list box returns no data, the whole form goes blank even if the first and third list box return Data. What could be the property I should change?

Things I tried:
- I deleted the second list box, than I duplicated the first list box and changed its condition. Same result.
- I deleted the second list box and everything went good, but this time, with only 2 list boxes, whenever the first list box returns no data, the whole form goes blank again.

Any help please.
Regards.

[sierra7]

Hi Dany
I'm not a fan of ListBoxes but will try and creat a blank one in a minute and get back.

I know that if there are calculated fields on a form and one goes wrong, then they all show an error.

I'm curious why your code works because Access usually wants dates inside hashes (#) eg

Select Id, Emp_name 
From Tbl_Employee 
Where Hire_date < #01/01/2010# 
 

What are your other criteria? Is it just that there are no results or is Access calling 'Foul!'?

Are you in the UK and putting in a UK date? If you put in today as '21/11/2011' Access will be wondering what month 21 is?

S7

[NeoPa]

I'm just wondering what you're not telling us. You don't say if the form is even bound. The only scenarios I can imagine where no records show are :

1. The ListBox is bound to a field and the record has a value for that field.
2. You are applying filtering based on these ListBoxes and you just didn't bother to tell us.

Either way it seems like a incomplete question (though to be fair, I notice it is well formatted and some effort was applied to make the question a good one, so no criticism due).

PS. Access (or more precisely Jet SQL) is too clever (unfortunately for many) to be confused by a date of 21/11/2011 (hence so many get confused by international dates in SQL). Where it falls over is in determining that a date of #7/6/2011# is intended by most Europeans to reflect 7th June because the SQL standards insist that should be done as m/d/yyyy, which would be #6/7/2011#. Most dates are determinable even though they're put in back-to-front (21/11/2011 makes no sense in SQL format so it guesses, correctly, that it should really have been 11/21/2011), which is why so many people fail to see they have their date literals the wrong way around until after the project is released.