correct criteria for date using cdate

SELECT CDate([txtDate]) AS [Date]
FROM tblData
WHERE (((CDate([txtDate]))< #[Forms]![frmStartUp]![txtToDate]#))  (this is an unbound text box with format set to short date)
ORDER BY CDate([txtDate]) DESC;

try that, the # signifies it as a date

won't let me just put in the #'s, also tried <"#" &[Forms]![frmStartUp]![txtToDate]&"#", but, didn't work either.
So, I tried just a fixed date, <#10/31/2006#, got a data type mismatch in criteria (after it briefly showed the data)  

can you give me an example of the data that's in txtDate in tblData?

Very odd, I created a mock up of what you did.  I created a form called frmStartUp with an unbound textbox on that form with a format of short date.  I also created a table called tblData with a field called txtDate.  the field I defined was text and i put the following data in it:

1/1/2006
1-5-06
2/22/06
3/12/06
6/6/06

then I copied your query exactly into a new query and it worked....what is the data like in your table?

If I run the query without the criteria, I get:
9/1/2005, 8/1/2006 (all dates set to the first)
The data in the table looks like (when viewed in notepad, it's a linked table, to a csv file):
Oct 2006

again very odd, I put in this data:

jan 2006
jun 2006
nov 2006
oct 2006
sept 2005

and it works fine.....make sure you've lost focus on the textbox in the form so that it saves the changes that you made...

yes, something seems strange. When I view the results of the query, I see the date as Nov-06. If I click on a date field, it changes to 11/1/2006. It is right justified, so, it knows it's not a text field.

hrm....do you mind posting your database or a portion of it at www.ee-stuff.com ? if you do you have to change the extension to .txt b/c it won't accet .mdb files

it will take a while, I'm in the middle of  doing 3 things, and the database is very large, so, I'll make up something smaller.

You are supposed to zip it, not change extensions.  

BTW, EE-Stuff.com has not been working for over 2 days.

thanks GRayL, I forgot that you can put in zip files...

In the design mode of the form, highlight the textbox with the date, rightclick Properties, format tab and beside Format enter -  mmm yyyy

Now when you enter a date, the system know it is to be a date, and you do not need the # delimiters.  You will also get an error message if your entry does not match any mmm yyyy format.

Always end up being overly explicit when you don't store date type data in a date type field :-S

Your first solution looked almost spot on to me though
SELECT CDate([txtDate]) AS [Dated]
FROM tblData
WHERE CDate([txtDate])<CDate([Forms]![frmStartUp]![txtToDate])
ORDER BY CDate([txtDate]) DESC;

You shouldn't delimit an expression in a query - you'd only do that when passing a value, as the expression is evaluated by Access.  Delimiters won't help that.
e.g.
SELECT CDate([txtDate]) AS [Dated]
FROM tblData
WHERE CDate([txtDate])<#12/12/2006#  (this is an unbound text box with format set to short date)
ORDER BY CDate([txtDate]) DESC;

LPruvis,
I thought that would have worked too, but, didn't make any difference.
There must be something wacky with the txt file that I'm just not seeing.

Text file?  (Or field?)

Can you provide some exact example data? (That is exemplary and exciting without being excruciating.... sorry :-)

Sometimes forms become busted.  If it is not a lot of work, delete the old form and start from scratch.  

MB, you might be right, I forgot about that. I'll be working with this more early next week. Thanks.

You never did get us that example data... :-)  http:Q_22046927.html#17862077
But let's hypothesize...

Nulls could indeed be a problem.  (Yikes.. text fields acting as dates... *and* Nulls?  :-S)

And I wouldn't be surprised if the general problem was then with built in function calls from SQL (or indeed it could be argued, an issue of Jet SQL itself).
First of all - if there are null values - you wouldn't be able to exclude them in the same clause - e.g. And X Is Not Null.  
So potential for an error there still.
OK then - so a subquery - where they are fitlered first to remove the Nulls.
Perhaps surprisingly - you still can't be totally sure that an evaluation won't be carried out in the main query on a record which you might think it shouldn't even see.
"OK then" you think... "so I'll save a query which limits the results".
Nope - Jet is one step ahead of you (so it thinks) - and trying to limit the results returned even from a separate query, walking up the query tree.

So - to user defined function calls
For example...
Paste the following in a standard module.

Function fDateConv(varVal, Optional varAlt) As Date
    If IsDate(varVal) Then
        fDateConv = CDate(varVal)
    Else
        If Not IsMissing(varAlt) Then
            fDateConv = CDate(varAlt)
        End If
    End If
End Function

Then go with a query of...

SELECT CDate([txtDate]) AS [Dated]
FROM tblData
WHERE fDateConv([txtDate],[Forms]![frmStartUp]![txtToDate]) < [Forms]![frmStartUp]![txtToDate]
ORDER BY CDate([txtDate]) DESC;

Notice the use of the built in function everywhere except the Where clause.
Naturally - it's safe to do so by then.

So, there was a bad record in the data causing the problems.

Here is what happens when the data is ok:

cdate([month]).....does convert to date and sorts by date, and looks like 9/1/2006 (which I presume is the system format)
format(cdate([month]),"mmm-yy")....comes out in the format I want, but, sorts by alpha (by month name)
cdate([month]).....and setting the field properties format to mmm-yyy, in the query design view, shows the format I want and sorts by date.