Really really dumb question. I'm working on a bit...
# cfml-general
d
Really really dumb question. I'm working on a bit of code that includes this: <cfqueryparam value="#arguments.updatedbyid#" cfsqltype="CF_SQL_INTEGER" null="#arguments.updatedbyid EQ this.badnumber#"> It's currently throwing this error: Invalid data '' for CFSQLTYPE CF_SQL_INTEGER. But if I put this on the line before that: <cfthrow message="arguments.updatedbyid=#arguments.updatedbyid#"> Then it throws this: arguments.updatedbyid=1234 That error makes sense, that's the integer value I expect. It should NOT throw "Invalid data '' for CFSQLTYPE CF_SQL_INTEGER ". I've restarted cf, in case it was lost in the weeds for some reason, though things seem fine otherwise. I also tried removing the null="..." bit, though it should be fine as is, no change. (This isn't the same server or even cf version as my last ghost in the machine, in case you're wondering...) Am I missing something obvious?
w
it's complaining that you're passing an empty string to that queryparam. if you wrap it in val
value="#val(arguments.updatedbyid)#"
i'm sure the error goes away, but doubt it's what you actually are expecting
👆 1
also unclear is whether arguments.updatedbyid has a leading space in it which may be tripping up its evaluation. you could try trim()ing it i suppose, but it doesn't address the fundamental issue that you are expecting a valid number and you're not getting it
c
you have to Val() it as for some reason the validation for the type check happens even if you want to null the row and would never be passing 0 into the row
d
I understand what the error is saying, it's just not true, as evidenced by the throw. I even added len(arguments.updatedbyid) to the throw, and it's 4, as expected. WTH?
c
would think if it were my code i have missed something and there is a case where "" or a non integer is being passed in
w
@chris_hopkins the null evaluation is independent of the value and happens first afaik. you can have things such as
null="!isNumeric(arguments.updatedbyid)#"
for example without issue
c
quite possible my experience of that was on an older version and i have not checked since
w
is this query or method happening in a loop? is it possible you're intercepting the wrong iteration and the data looks correct when it's another iteration's values that are jacked?
d
I Thing is, adding this right before that line: <cfthrow message="arguments.updatedbyid=#arguments.updatedbyid# len=#len(arguments.updatedbyid)#"> ... throws this, as expected: arguments.updatedbyid=1234 len=4 Makes no sense.
w
include
isNumeric(arguments.updatedbyid)
as well in that throw, what's that result
🍿 1
and/or an
abs(arguments.updatedbyid)
just to see if it behaves as numeric
d
@websolete Must be something like that, though I haven't been able to prove it. It's not in a loop.
Re multiple iterations etc, I added this before the code I've been talking about: <cfif structKeyExists(request, "alreadyRanThis")> <cfthrow message="We already ran this."> <cfset request.alreadyRanThis = true> </cfif> It doesn't throw there, so that's the first (should be only) time in the request that this code runs.
w
the thick plottens
d
arguments.updatedbyid=1234 len=4 isNumeric=YES abs=1234
w
is that the only parameter in the query?
☝️ 2
f
I had my money on non-visible character in the value… guess not
but… for your multiple iterations shouldn’t this
<cfset request.alreadyRanThis = true>
be in a
else
d
@foundeo yup, oops, I'll fix, one sec.
Moved <cfset request.alreadyRanThis = true> outside the cfif, no change, as expected, it should only be running once.
All the other params in this query are done in a loop, and shouldn't include updatedbyid. Just to be sure, I put a throw in that loop if the field is updatedbyid, didn't throw. The non-loop param that's blowing up appears to be the only use of updatedbyid, as expected.
f
try changing the
cfsqltype
to
cf_sql_varchar
temporarily on the updatedbyid if you are still getting
Invalid data '' for CFSQLTYPE CF_SQL_INTEGER
then it is not from that var
w
for that last suggestion you'd expect a 'cannot cast '' to type integer' or something from the db rather than cf if it fails
f
if you still get the error keep changing cfqueryparam cfsqltypes one by one until you find which one it is
and if you are getting
'cannot cast '' to type integer'
then somewhere in your code that variable is getting changed, try moving your throw around to different places to see where it gets set to
''
d
You could also try hard coding the value "1234" in the queryparam, or just temporarily replacing the queryparam with a hard-coded 1234. The query should complete without error if that's really where the problem is.
How did you determine that updatedbyid is the variable that's causing the error? The error message doesn't tell you that, does it? Did you use the line number?
d
@David Buck yes that's the line number reported, and the line in bold in the crash msg on the page. However, I temporarily hard coded the value in the cfparam statement, got the same error, on that same line, so I think you're right that the error probably isn't about that specific param. Investigating...
👍 1
Got it, bad default value for an upstream argument that wasn't passed, not the one indicated in the error. Generic abstractions made it harder to find than it should have been.
1