tracker issue : CF-3039412

select a category, or use search below
(searches all categories and all time range)
Title:

Bug 79024:(Watson Migration Closure)I use: where FIELD in ( <cfqueryparam type="varchar" value="#valueList( query

| View in Tracker

Status/Resolution/Reason: Closed/Deferred/

Reporter/Name(from Bugbase): David McGuigan / David McGuigan (David McGuigan)

Created: 07/23/2009

Components: Database, CFQuery

Versions: 9.0

Failure Type: Unspecified

Found In Build/Fixed In Build: 0000 /

Priority/Frequency: Normal / Unknown

Locale/System: English / Platforms All

Vote Count: 2

Problem:

I use: where FIELD in ( <cfqueryparam type="varchar" value="#valueList( query.field )#" list="yes" /> )a lot, but a lot of the time I need to match to values in an array. You can use arrayToList pretty easily to pour those values into a cfqueryparam, unless some of your array values have commas or variability that makes choosing a new delimiter haphazard. But what would really empower cfqueryparam is the ability to pass in arrays and have them correctly execute as segregated prepared arguments WITHOUT manual preparation.In the implementation, I would prefer to not have to specify an array="true" parameter and have cfqueryparam detect the array and execute seamlessly, but some people will probably prefer the explicit denotation ( optional? ).Either way, array support for cfqueryparam would add new functionality ( let you match to values with commas without doing the work of choosing and injecting a separate delimiter and denoting it in your cfqueryparam ), as well as improve the flexibility ( and maybe performance? ) of cfqueryparam.
Method:


Result:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3039412

External Customer Info:
External Company:  
External Customer Name: David McGuigan
External Customer Email: 5E0D54C04462BF5E992016B6
External Test Config: 07/23/2009

Attachments:

Comments:

+1 vote: good suggestion. -- Adam
Vote by External U.
23252 | November 10, 2011 06:59:42 PM GMT
+1 David already mentioned the advantages of this. I'd say we do NOT need an extra parameter "array" here (even not optionally), because it is a clear case when an array is passed. The "list" parameter is just existing, because it is not clear, if the value should be parsed as normal value or as list.
Vote by External U.
23253 | November 10, 2011 06:59:43 PM GMT