Does this give you the results you are expecting?

DaysOpen: IIf(Not IsNull([WaitingDate]) And IsNull([ClosedDate]),[WaitingDate]-[CCDate],IIf(Not IsNull([WaitingDate]) And Not IsNull([ClosedDate]),[ClosedDate]-[CCDate],IIf(IsNull([WaitingDate]) And Not IsNull([ClosedDate]),[ClosedDate]-[CCDate],Date()-[CCDate])))

I copied and pasted the formula above....
I still get the following error:
The expression you entered has an invalid . (dot) or ! operator or invalid parentheses.
You may have entered an invalid identifier or typed parentheses following the Null constant.

Where are you entering it?
I used a query and it worked perfectly.

Thank you for your help.  I can get it to work in a query- but that created other concerns on another form.  I was trying to see if I could get it to work as a calculated field in a table.

Calculated Fields in Tables - Evil Access Stuff

Kevin's right. This works fine in a query, but calculated fields in tables are very limited and are usually not where you want to put logic like this.

Table-level calculated fields sound handy at first, but once you need anything beyond a simple expression, they turn into a Ferengi contract. Lots of rules, lots of restrictions, and somehow you still don't get what you actually want.

In Access, this kind of calculation is much better handled in a query, on a form, or in a report, depending on where you need to use it. Once you start involving multiple dates, Null checks, and conditional logic, table calculated fields become more trouble than they're worth.

Also, from a design standpoint, values like Days Open and Days Waiting are derived values, not data you should store in the table anyway. They should be calculated when needed based on the actual dates so they always stay accurate.

So yes, query = good. Table calculated field = usually no bueno.

Thank you.  I'll work it out with the query.