This expression is typed incorrectly

[Ray67]

Hello all,

I am experiencing this error:

"This expression is typed incorrectly or it is too complex to be evaluated….For example a numeric expression my contain too many complicated elements."



I'm using this expression:
Between [Forms]![F_DeptofMedicineGLAccountUpdate/EditForm]![servicefrom] And [Forms]![F_DeptofMedicineGLAccountUpdate/EditForm]![serviceto]

I'm i doing something wrong????

Thank you

[alansidman]

You have a forward slash (/) in your form name. This symbol is a reserved character in Access and it causes problems when used in form names and field names. This may be the issue. Try changing it.

Here is a listing of reserved names and characters.

http://office.microsoft.com/en-us/ac...010030643.aspx

Alan

[June7]

Where are you using this expression?

Alan, doesn't including in brackets make the / accepted? I do advise not using punctuation (underscore is exception), special symbols, spaces in names.

[Ray67]

I take off forward slash (/) now its works

Thank you alan

[alansidman]

June;
The brackets may work. I just prefer to stay away from reserved characters.

Alan

[mitchmcc]

Alan,

I found this thread via Google. I am getting the same error on an Access project
I inherited, but only when I start up Access. Of course, in this case there is absolutely no indication of *which* query or report Access is unhappy about.

How can I find this? I have gone through every normal query and do not see any issues, and in fact, can run them. I *suspect* that there may be a query on a report that I have not found yet.

Is there any log in Access that would tell me exactly what "expression" it is complaining about?

Thanks,

Mitch

[June7]

If this happens when project opens the issue is in code that executes when project opens. This could be an Autoexec macro or form that is set as default for the project. Are you running mdb/accdb (as opposed to mde/accde compiled executable)? Hold down the shift key as mdb/accdb file opens. This should override Autoexec and many default project settings, such as the default open form. This should offer clue on where to look.

I agree, avoid spaces, special characters, punctuation (underscore is exception) in names and reserved words as full names. I just thought the brackets would make the code accept them. Something even more special about /?

[mitchmcc]

As far as I know, I do not have any macros. I also tried your suggestion about opening the MDB with the shift key, and it did not change the 3 separate warnings I get.

My current theory is that there are queries attached to controls (usually listboxes) that refer to hidden textboxes. Normally, the Form Load procedure appears to try and make sure that these get populated by
forcing a "Click" event whose VBA code sets the textbox. As I had added a few new listboxes that behaved similarly, I also tried to add equivalent behavior, but to no avail.

Another weird thing is that after getting these 3 warnings, the app itself seems to behave perfectly fine!

While testing, I took one of these queries and manually created a new query and tried to run it, and saw the problem occur. So initially, I thought
"I found it". I assume that by running the query (when I am in design mode, BTW), that the reference to the Form textbox simply was not set, and that was what was causing the problem at startup as well. The problem with this theory is that the original application had many similar queries just like this one, and did not have these warnings. This makes me think that there is some other stupid issue somewhere.

Here is an example of the one I mentioned above:

SELECT [Certification List].ID, 
[Certification List].Certification, 
[Group List].Group, 
[Group List].ID 
FROM [Group List] 
INNER JOIN ([Certification List] 
INNER JOIN [Group Certifications] ON [Certification List].ID=[Group Certifications].Certification_Id) 
ON [Group List].ID=[Group Certifications].Group_Id 
WHERE ([Group List].ID=CInt(forms.[Employee Certification Tracking].txtGroupCertsGroupId));

The textbox item is the "forms.[Employee Certification Tracking].txtGroupCertsGroupId)".

Thanks for helping me work through this!

Another post somewhere mentioned that a type mismatch might be the culprit. I initially thought
that might be my problem, as I had a couple of places where I was testing a text field on the form
to an integer ID value from the table. So I surrounded one of these places with the CInt function,
but 1) it did not change the behavior, and 2.) the original app had several places where it did NOT
use CInt (and others where it did).

Mitch

If this happens when project opens the issue is in code that executes when project opens. This could be an Autoexec macro or form that is set as default for the project. Are you running mdb/accdb (as opposed to mde/accde compiled executable)? Hold down the shift key as mdb/accdb file opens. This should override Autoexec and many default project settings, such as the default open form. This should offer clue on where to look.

I agree, avoid spaces, special characters, punctuation (underscore is exception) in names and reserved words as full names. I just thought the brackets would make the code accept them. Something even more special about /?

[June7]

Interesting that something is still trying to run and throwing errors even with holding down the shift while opening. Do you want to provide project for analyis?

[mitchmcc]

Believe it or not, I was able to get rid of all 3 instances of this error message.
The way I did it was to use the "Nz" function on a couple of the textbox form fields that were being used.

I also put in initial string values for the other textboxes that represented numbers.

These two "fixes" (I am not happy about them) seem to make Access happy.

So for now, I am going to proceed.

Thanks for your offer... perhaps I'll be back (ominous music here)..

Mitch

Interesting that something is still trying to run and throwing errors even with holding down the shift while opening. Do you want to provide project for analyis?