Dan Roberts just pointed out this very strange bug to me; apparently in ColdFusion the strings "0" (zero) and "A" are not equal unless they are preceded by zeros, in which case they are considered equal. I am sure this is a known bug, but I had never seen it, so I thought I would throw it out there.
To test this, I ran a bunch of comparison tests to see what worked and what failed:
Launch code in new window » Download code as text file »
None of these should come out as being equal, but running the above code gives us the following output:
00A EQ 000
00A EQ 000 (Using CF ToString())
00A EQ 000 (Using Java ToString())
00A NEQ 000 (using Java Equals())
00A NEQ 000 (using Compare)
00A NEQ 000 (using CompareTo())
As you can see, the standard ColdFusion "EQ" operator works on all string values (no matter how that string value was generated). But, all of the more "Java-oriented" and character-wise approaches truthfully tell the two strings apart. This doesn't seem to happen with anything but "0" and "A". Very strange.
Download Code Snippet ZIP File
Comments (20) | Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Team Schwarzenegger At CFUnited Express New York City (NYC)
My AJAX / ColdFusion Response Framework (er, um ...Methodology)
I would let the CF team know.
Posted by Sami Hoda on Mar 6, 2007 at 6:39 PM
I submitted a bug report to Adobe not much earlier today.
Thanks for testing all of the equality functions/operators. I had to add some extra code to deal with this but will probably just switch it out with Compare() tomorrow.
Posted by Dan Roberts on Mar 6, 2007 at 6:49 PM
@Dan,
I would be curious to know how you even found this?!? Also as far as moving to the Compare() method... you probably want to move to CompareNoCase() as it is case-insensitive and the EQ operator is also case-insensitive.
Posted by Ben Nadel on Mar 6, 2007 at 6:53 PM
The company I work for manages a database of federal and states legislators. For some odd reason my boss decide way back when that the district field should have leading zeros, which he says makes it easier to eyeball problems. For example a district 1 is 001, a district A is 00A and officials without a district have 000. I was checking for district fields of 000 and of course ran into problems when records with 00A matched as well.
This came up a couple years ago but I just threw in a quick IsNumeric check which 00A fails on. That worked so I commented about the problem and moved on. Saw the comment today and thought it was about time I should bring it to their attention.
Posted by Dan Roberts on Mar 6, 2007 at 7:06 PM
Hi,
just did a small test and found that the IS operator behaves just like EQ.
Chris
Posted by Christoph Schmitz on Mar 7, 2007 at 2:48 AM
The following link has some interesting information on the subject.
Regarding the above problem it says:
"Short strings, such as 1a and 2P, can produce unexpected results. ColdFusion can interpret a single "a" as AM and a single "P" as PM. This can cause ColdFusion to interpret strings as date-time values in cases where this was not intended."
So coldfusion is comparing 0:00 AM to 0:00 AM.
Posted by Gary Boyle on Mar 7, 2007 at 6:48 AM
@Gary,
Nicely done! I guess this is ColdFusion's attempt to make things super easy for people to use (and at the same time, sacrificing a tiny bit of predictability). I certainly do love how easy it is to compare date/times in CF.
Posted by Ben Nadel on Mar 7, 2007 at 7:53 AM
Thanks Gary. That gives me some idea of what's probably going on.
Oddly though I can only get it to happen with EQ using 0 and 0A. Doesn't happen with 1 and 1A for example or 13 and 1P. GT and LT only compare like this if you include letters on both strings. Anyways, something to keep in mind.
Posted by Daniel Roberts on Mar 7, 2007 at 9:30 AM
1 and 1a dont work because coldfusion turns the time into a fraction.
So for example the values
<cfset strA = "0.25" />
<cfset strB = "6A" />
would work. As strB is turned into 6:00 AM which is a quarter of a day (6/24 = 0.25).
Posted by Gary Boyle on Mar 7, 2007 at 9:41 AM
@Daniel:
Try "1p" EQ "13:"
Note the colon which, I guess, makes CF believe the string actually is the hour part of a time value.
Best,
Chris
Posted by Christoph Schmitz on Mar 7, 2007 at 9:43 AM
I recently had a somewhat similar problem with some floating point values in CF. I was comparing values from records in two different sets of SQL Server query results, values that when cfdumped to the screen were exactly the same, yet the EQ comparison always evaluated as false. I tried doing a javacast() of both values to double and comparing them, but the EQ still came back false. Again, cfdumping the returned values from javacast() seemed to confirm they were the exact same values. So I tried converting the values using DecimalFormat(). The EQ comparison correctly evaluated as true.
Posted by Jeremy on Mar 7, 2007 at 12:46 PM
Thought you guys might find it interesting to know the results of this code on Scorpio and BlueDragon (I have access to both). Scorpio is identical to CF 7, so they haven't 'fixed' this (yet). However, BlueDragon does it all correctly:
http://techfeed.net/000-00A.cfm
Posted by Jacob Munson on Mar 7, 2007 at 2:36 PM
Go Blue Dragon! I can't wait to get my hands on Scorpio!
Posted by Ben Nadel on Mar 7, 2007 at 2:39 PM
We are lucky enough to have an ex-Adobe employee on our team, and he was able to get us a copy of Scorpio Beta. I wish I could share some of the new stuff they've got in there, but maybe it suffices to say that I'm very excited about the additions. And I'm not talking about all the boring Adobe product integration we've already heard about.
Posted by Jacob Munson on Mar 7, 2007 at 3:15 PM
I want to see if I can get a Beta. Apparently there is some program for it... time to do some snooping.
Posted by Ben Nadel on Mar 7, 2007 at 3:17 PM
@Ben,
AFAIK the Scorpio Beta is public. Ben Forta posted a link to the Adobe Prerelease Program in his blog: http://www.forta.com/blog/index.cfm/2007/1/22/Anyone-Want-To-Beta-Test-Scorpio
Best,
Chris
Posted by Christoph Schmitz on Mar 7, 2007 at 3:26 PM
Thanks Chris!
Posted by Ben Nadel on Mar 7, 2007 at 3:30 PM
can i use a wildcard when comparing in coldfusion
for example
<cfif #variable# eq 'AE%'>
Posted by justin on Apr 10, 2007 at 12:52 PM
You cannot use a SQL wild card when comparing values. However, you can use a regular expression and the REFind() function.
Take:
<cfif #variable# eq 'AE%'>
and make it into:
<cfif REFind( "^AE.+?", variable )>
The "^" means match at the beginning of the string.
AE is the literal string you are looking for.
.+? means at least ONE character after AE but don't bother checking more than one. You can probably remove this and JUST use "^AE", but it depends on what you want to do.
Regular expressions are totally awesome. If you want to know more about them, check out this primer:
http://www.bennadel.com/index.cfm?dax=blog:458.view
Posted by Ben Nadel on Apr 10, 2007 at 12:56 PM
@Justin,
CFML supports the CONTAINS operator:
<cfif variable CONTAINS 'AE'>
Just keep in mind that this operator is case insensitive, like all basic decision operators in CFML.
For more information, take a look at the docs: http://livedocs.adobe.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ColdFusion_Documentation&file=00000928.htm
Chris
Posted by Christoph Schmitz on Apr 10, 2007 at 2:27 PM