Error 2448 does not make sense in the context of the problem

[DataBard007]

Hello Access Gurus:

I use Win98SE and Access97.
I just built a simple Access97 application which holds all contact
information for my personal contacts, such as first name, last name,
address, city, state, etc.
When the user wants to search for a particular record, he does two
things:
1. On the form is a text box on which he enters the text he is searching
for.
2. Then he clicks on an option button to choose which field the search
will be conducted on, e.g., First Name field, Last Name field, etc.
E.g., click the "First Name" option button and type "John" in the text
box to search for records of contacts named John.
Then he clicks a cmdFind button and the code applies a Filter to the
form and finds and displays the record in the underlying table that
contains the text that was entered in the text box.
The trouble is that when I enter an apostrophe in the Search box, I get
the error message "Error 2448. You can't assign a value to this object."
This does not make sense to me because I'm not trying to assign a value
to any object.
I do think I know what is going wrong however. When I put the
apostrophe in the search string, the Filter property does not make sense
because the apostrophe interferes with the proper concatenation of the
different parts of the filter condition (e.g., Me.Filter = SearchField &
" Like '*" & SearchValue & "*'") where SearchValue is the value to be
filtered on, i.e., the value that is entered in the textbox. So if an
apostrophe is entered, the Filter condition is all wrong.

HERE ARE MY TWO QUESTIONS
1. If that's the reason things are going wrong, why do I get error
message "Error 2448. You can't assign a value to this object." It
doesn't seem to make sense based on what the real problem is.
2. Perhaps most importantly:
Is there any resouce on the web that contains Help files that help
developers to understand what causes certain error messages? There's a
ContextID associated with each error message, but where are the help
files that they refer to? They're certainly not part of Access97. If
such a resource existed on the web, it would be of great help to me.

Thanks to anyone who can help me with this.

Patrick


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Allen Browne]

You don't mention which line gives this error, but I'm guessing it's the
line where you assign the string to the form's Filter. If so, Access is
saying that you cannot assign the string to the filter - not becuase a
filter can't accept a string, but because the attempt to assign this string
failed. The reason is failed is as you observed: the extra apostrophy means
the string is not well-formed for a filter.

As a workaround you might consider embedding double-quotes in the string:
strFilter = "Surname = """ & Me.txtWhat2Find & """"
That will still barf if the user enters a double-quote in the string, but
tha'ts less frequent. If you want to go the next level, you can use the
Replace() function to replace """" with """""" so the double-quote character
is doubled up within the string. Ah: you're using A97, so you would have ot
write your own Replace().

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"DataBard00 7" <an*******@devd ex.com> wrote in message
news:3f******** *************@n ews.frii.net...

Hello Access Gurus:

I use Win98SE and Access97.
I just built a simple Access97 application which holds all contact
information for my personal contacts, such as first name, last name,
address, city, state, etc.
When the user wants to search for a particular record, he does two
things:
1. On the form is a text box on which he enters the text he is searching
for.
2. Then he clicks on an option button to choose which field the search
will be conducted on, e.g., First Name field, Last Name field, etc.
E.g., click the "First Name" option button and type "John" in the text
box to search for records of contacts named John.
Then he clicks a cmdFind button and the code applies a Filter to the
form and finds and displays the record in the underlying table that
contains the text that was entered in the text box.
The trouble is that when I enter an apostrophe in the Search box, I get
the error message "Error 2448. You can't assign a value to this object."
This does not make sense to me because I'm not trying to assign a value
to any object.
I do think I know what is going wrong however. When I put the
apostrophe in the search string, the Filter property does not make sense
because the apostrophe interferes with the proper concatenation of the
different parts of the filter condition (e.g., Me.Filter = SearchField &
" Like '*" & SearchValue & "*'") where SearchValue is the value to be
filtered on, i.e., the value that is entered in the textbox. So if an
apostrophe is entered, the Filter condition is all wrong.

HERE ARE MY TWO QUESTIONS
1. If that's the reason things are going wrong, why do I get error
message "Error 2448. You can't assign a value to this object." It
doesn't seem to make sense based on what the real problem is.
2. Perhaps most importantly:
Is there any resouce on the web that contains Help files that help
developers to understand what causes certain error messages? There's a
ContextID associated with each error message, but where are the help
files that they refer to? They're certainly not part of Access97. If
such a resource existed on the web, it would be of great help to me.

Thanks to anyone who can help me with this.

Patrick

[DataBard007]

Thanks Allen:

Yes, you were right about the line that caused the error.
Thanks for your suggestion, but I still don't know:
1. Why Access gave this particular error message, which did not give me
any idea as to what the true cause of the problem was?
2. Is there a resource somewhere in the web that has Help files that
help you to determine what causes particular errors? In this case, I was
able to figure out the cause of the problem, but in another case, I may
not be able to without a help file.
Thank You.
Patrick

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Michael \(michka\) Kaplan [MS]]

"DataBard00 7" <an*******@devd ex.com> wrote...

Yes, you were right about the line that caused the error.
Thanks for your suggestion, but I still don't know:
1. Why Access gave this particular error message, which did not give me
any idea as to what the true cause of the problem was?
Well, the error messages are not always helpful. Often the level at which
they fail is low enough that the piece that failed does not have good
information to put in an error. It is simply life and spending more time
looking at the code ethast caused the error and less time trying to
understand when the error message are obscure will maximize your chances of
success.
2. Is there a resource somewhere in the web that has Help files that
help you to determine what causes particular errors? In this case, I was
able to figure out the cause of the problem, but in another case, I may
not be able to without a help file.

There is really not something like this. Some error messages are helpful,
some are not. And even if the errors were great, good debugging skills are a
lot more important, and useful.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

[Allen Browne]

Like michka, I don't think this is a matter of finding a resource about
errors, as it it developing a mindset about how to understand them. A couple
more examples may help.

Open the Immediate window (Ctrl+G) and enter:
? DLookup("zzz", "MyTable")
where MyTable is the name of a table, and "zzz" is a misspelling for a field
name (i.e. the table does not have a field named "zzz"). VBA responds:
Error 2001: You canceled the previous operation"
DLookup() is a high-level function. It passes the request down and discovers
that it failed, but it does not know where it failed. It yields an error
saying that the problem occurred lower down.

Another example. To force Access to save the record in a bound form, we use:
Me.Dirty = False
because that's the only way to specify which form to save (not just the one
that has focus) and receive an error message if the save failed for some
reason (e.g. a validation rule is not met). If Access cannot set the Dirty
property, the actual error message can be (amongst others):
The property cannot be set
At first glance, you might think it is saying the Dirty property is
read-only, especially as the property *was* read-only back in the days of
Access 1 and 2. The reality is that this high-level attempt to set the
property failed at a lower level (e.g. because a required field was
missing), and so VBA quite correctly tells you that setting the property
didn't work this time.

Occassionally an error message is very hard to follow. This line of code
worked fine in the original Access 97:
DoCmd.TransferT ext acImportDelim,, "MyTable", "C:\MyFile. prn"
However, in Access 2000, it generated the error:
Database is read-only
The problem was that "prn" is not a registered file type for text files, so
TransferText could no longer process it. The error message was miles off!
Fortunately, you don't come across that level of disparity between error and
message very often, and I think MS changed the handling of this error in
A2002.

In the early days of Windows, people used to tease Microsoft because of the
number of error messages. Taglines such as:
Error 2800578##!@ - Out of error messages!
Now, we have come to appreciate the thousands of error messages in our
products, and how - with a bit of experience - they do point you towards a
useful resolution of most problems.

One day I hope to get around to writing an article called, "Error messages
are your friends."

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Michael (michka) Kaplan [MS]" <mi*****@online .microsoft.com> wrote in
message news:3f******@n ews.microsoft.c om...

"DataBard00 7" <an*******@devd ex.com> wrote...

Yes, you were right about the line that caused the error.
Thanks for your suggestion, but I still don't know:
1. Why Access gave this particular error message, which did not give me
any idea as to what the true cause of the problem was?
Well, the error messages are not always helpful. Often the level at which
they fail is low enough that the piece that failed does not have good
information to put in an error. It is simply life and spending more time
looking at the code ethast caused the error and less time trying to
understand when the error message are obscure will maximize your chances

of success.

2. Is there a resource somewhere in the web that has Help files that
help you to determine what causes particular errors? In this case, I was
able to figure out the cause of the problem, but in another case, I may
not be able to without a help file.
There is really not something like this. Some error messages are helpful,
some are not. And even if the errors were great, good debugging skills are

a lot more important, and useful.

[Tony Toews]

"Allen Browne" <Al*********@Se eSig.Invalid> wrote:

One day I hope to get around to writing an article called, "Error messages
are your friends."

FWIW these kinds of misleading error messages I encounter or non existent such as the
- errors I always try to put on my website for reference purposes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[David W. Fenton]

Al*********@See Sig.Invalid (Allen Browne) wrote in
<3f************ **********@free news.iinet.net. au>:

Another example. To force Access to save the record in a bound
form, we use:
Me.Dirty = False
because that's the only way to specify which form to save (not
just the one that has focus) and receive an error message if the
save failed for some reason (e.g. a validation rule is not met).
If Access cannot set the Dirty property, the actual error message
can be (amongst others):
The property cannot be set
At first glance, you might think it is saying the Dirty property
is read-only, especially as the property *was* read-only back in
the days of Access 1 and 2. The reality is that this high-level
attempt to set the property failed at a lower level (e.g. because
a required field was missing), and so VBA quite correctly tells
you that setting the property didn't work this time.
I think it was not until A95 or A97 that the .Dirty property
existed, and it was not read-only at any point.

But I could be wrong -- it could have been one of the many things I
didn't know about for a long time. No, the A97 help topic on new
features says that .Dirty was new in A95.

It always struck me as inelegant that you could set the .Dirty
property, but, I am certainly glad that you can!
Occassionall y an error message is very hard to follow. This line
of code worked fine in the original Access 97:
DoCmd.TransferT ext acImportDelim,, "MyTable", "C:\MyFile. prn"
However, in Access 2000, it generated the error:
Database is read-only
The problem was that "prn" is not a registered file type for text
files, so TransferText could no longer process it. The error
message was miles off! Fortunately, you don't come across that
level of disparity between error and message very often, and I
think MS changed the handling of this error in A2002.

Actually, you'd get this error in A97 with SR2 applied.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[DataBard007]

Tony Toews wrote:

"FWIW these kinds of misleading error messages I encounter or non
existent such as the - errors I always try to put on my website for
reference purposes.
WHAT!?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[DataBard007]

MichKa Wrote:

"Well, the error messages are not always helpful. Often the level at
which they fail is low enough that the piece that failed does not have
good information to put in an error. It is simply life and spending more
time looking at the code ethast caused the error and less time trying to
understand when the error message are obscure will maximize your chances
of
success."

Thanks for clarifying this for me MichKa.
When I saw the incomprehensibl e error message, it made me think that
there was some obscure information that had to be researched in order to
be able to solve the problem. But you're saying that it only means the
true cause of the problem was not determined by Access.
As I understand you, the bottom line is, if the error message is useful,
then use it. If it's not, just ignore it and debug the problem
yourself. Is that basically it?

Patrick

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Michael \(michka\) Kaplan [MS]]

Well, not always ignore it, so much as move and try to look for clues based
on the failure itself. Sometimes after you fo that you understand what the
error message was [inadequately] trying to get at. :-)
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"DataBard00 7" <an*******@devd ex.com> wrote in message
news:3f******** *************@n ews.frii.net...

MichKa Wrote:

"Well, the error messages are not always helpful. Often the level at
which they fail is low enough that the piece that failed does not have
good information to put in an error. It is simply life and spending more
time looking at the code ethast caused the error and less time trying to
understand when the error message are obscure will maximize your chances
of
success."

Thanks for clarifying this for me MichKa.
When I saw the incomprehensibl e error message, it made me think that
there was some obscure information that had to be researched in order to
be able to solve the problem. But you're saying that it only means the
true cause of the problem was not determined by Access.
As I understand you, the bottom line is, if the error message is useful,
then use it. If it's not, just ignore it and debug the problem
yourself. Is that basically it?

Patrick

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!