Sarah said:
Roy,
I do not think this is the problem. I'm able to do number
comparisons elsewhere in my code and besides a comma would equal a
comma. Therefore how could this be the problem. (i.e 46,5 = 46,5).
Germans also use periods in the date field and we use slashes which
isn't a problem. Thanks for your input.
RoyVidar said:
<
[email protected]>:
Double
:
Sarah wrote:
It works fine here in the U.S., but
for some strange reason it would not work in Germany. If I
removed the criteria, it worked, but didn't get the result I
wanted. If I converted the THJPH and WorstJPH to strings, then
it would also work.
Just curious, what data type was TheJPH and WorstJPH before you
converted them to strings? Currency? Decimal?
Thanks.
--
Message posted via AccessMonster.com
I think Germans use comma as decimalseparator, which will make such
statement barf - try replacing the comma with a dot (.) ...
DLookup("TheJPH", "qryWorstCaseJPH01", "TheJPH=" & _
Replace([WorstJPH], ",", "."))
Do a small test, enter regional settings, change your settings to
German (Germany). Number format should look something like
123.456.789,00 in the regional settings thingie.
Then enter immediate pane (ctrl+g), and try/run these:
n = 1.5
? "testing" & n
Then try
? DLookup("TheJPH", "qryWorstCaseJPH01", "TheJPH=" & n)
(would you be getting a 3075 stating something about comma?)
and
? DLookup("TheJPH", "qryWorstCaseJPH01", "TheJPH=" & _
Replace(n, ",", "."))
What you are doing is not number comparision, but concatenating a
string which you pass to the domain aggregate function. With german
settings, the decimal sign you get when you do an implicit conversion
to string, is comma, which will, as stated, make such statements (and
dynamic SQL with decimals/fractions) barf.