Strange SQL issue
I have a very strange SQL issue in a query.
2 fields exist in a table: EmailFirstName and EmailLastName.
I created a column in the query and concatenated these to fields together.
FullName: [emailfirstname] & " " & [emaillastname]
Notice the e-f-n and e-l-n letters are low case although the table field names are uppercase.
This query works well on PCs from China, Poland, Texas, everywhere in the world but 1 (one) PC err'd on the "emiallastname" part of the concatenated field (in Mexico). PS. Other's in Mexico ran OK, this is just on ONE PC.
I dissected this issue and discovered that as long as the "L" in emaillastname was uppercase, the query WOULD WORK.
Low case in all the other letters worked.
This PC was replaced with a new one (not sure, but probably all existing software replaced also).
I was happy to find, at least, a work-around... but I hate these kinds of mysteries.
Win 7, Access 2010
Can anyone shed any light on this?
Scott C
2 fields exist in a table: EmailFirstName and EmailLastName.
I created a column in the query and concatenated these to fields together.
FullName: [emailfirstname] & " " & [emaillastname]
Notice the e-f-n and e-l-n letters are low case although the table field names are uppercase.
This query works well on PCs from China, Poland, Texas, everywhere in the world but 1 (one) PC err'd on the "emiallastname" part of the concatenated field (in Mexico). PS. Other's in Mexico ran OK, this is just on ONE PC.
I dissected this issue and discovered that as long as the "L" in emaillastname was uppercase, the query WOULD WORK.
Low case in all the other letters worked.
This PC was replaced with a new one (not sure, but probably all existing software replaced also).
I was happy to find, at least, a work-around... but I hate these kinds of mysteries.
Win 7, Access 2010
Can anyone shed any light on this?
Scott C
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The "codepage" is, basically, the "interpreter" which helps with localization of an application. Wikipedia defines it as " It consists of a table of values that describes the character set for a particular language", which is fairly accurate. Most of them are supersets of ASCII, which is just a numeric representation of a character set (i.e. A=101, B=102 etc). If that codepage were corrupted, it's entirely possible that Access would interpret your field names incorrectly, and not be able to compare them correctly.
At a basic level, ..it just sound like this one user changed something in Windows
(Regional settings, ...etc)
Did this one PC *always* have this issue?
See here...
http://www.ascii.ca/cp852.htm
Certain (but not all) Latin characters have a "Caron" or "Acute"
The Latin Letter "L" is one such character that hast both iterations for upper and lower case.
This is why I like to keep my names consistence in their "Case"...
FullName: [EmailFirstName] & " " & [EmailLastName]
I know VBA allows lets you "get away with" using either case, but most other languages do not.
JeffCoachman
(Regional settings, ...etc)
Did this one PC *always* have this issue?
See here...
http://www.ascii.ca/cp852.htm
Certain (but not all) Latin characters have a "Caron" or "Acute"
The Latin Letter "L" is one such character that hast both iterations for upper and lower case.
This is why I like to keep my names consistence in their "Case"...
FullName: [EmailFirstName] & " " & [EmailLastName]
I know VBA allows lets you "get away with" using either case, but most other languages do not.
JeffCoachman
ASKER
I will investigate these suggestions. Thanks much!!
Scott C
Scott C
ASKER
I've not found anything else specific on this issue, but I believe this is the closet I'll (probably) get to a solution - or explanation. I believe it has something to do with Windows and a language issue.
Thanks for your response. It's appreciated!
Scott C
Thanks for your response. It's appreciated!
Scott C
ASKER
What is the "codepage"?
Thanks
Scott C