<cfqueryparam cfsqltype="CF_SQL_INTEGER" value="">
<cfqueryparam cfsqltype="CF_SQL_INTEGER" value="">
But only in QoQ?
It happens with sql server as well
and in the sql debug, it shows up somewhat confusingly as
where id = [CF_SQL_INTEGER]
where id = [CF_SQL_NUMERIC]
when I’m assuming it’s actually passing in null?
and if i change the datatype to VARCHAR,
<cfqueryparam cfsqltype="varchar" value="">
it throws Error converting data type nvarchar to numeric.
Lucee handles null a whole lot better than ACF and, to my mind, Lucee has this right. I’d suggest filing a bug for ACF at https://tracker.adobe.com/
That’s JDBC semantics (to have “typed” nulls) in a parameter replacement, as it usually would get turned into
DECLARE @p0 int=null SELECT * from table where id=@p0
(Slight oversimplification to remove the sp_prepare and execute and unprepare bits)
Proper way to do this in ACF IMHO would be
<cfqueryparam cfsqltype="cf_sql_integer" value="#Trim(v)#" null="#Not Len(Trim(v))#" />
where v is your incoming variable. That’s what we do all over our codebase for inserts, or updates where you’re adding or changing a value to a null.
With an update we’d wrap that in a
<cfif StructKeyExists(arguments,"v")> for conditional updating semantics.
But I think in your case you need to revisit your strategy. SQL would error if you gave it the query
SELECT * FROM sometable WHERE id='', that CF does also doesn’t seem to be a CF problem.
And what are you trying to accomplish?
WHERE id='' is not valid, nor is
WHERE ID=NULL - you’d need to change your query to do IS NULL if that’s truly what you want.
WHERE <cfif not Len(Trim(v))> id IS NULL <cfelse><cfqueryparam cfsqltype="cf_sql_integer" value="#Trim(v)#" /></cfif>
IMHO that’s the programmers responsibility, just as it would be to make sure v is actually a number, instead of something like “J”. Realizing that CF believes something like “1e1” is a number, while SQL doesn’t (in MSSQL you’d have to pass it as a float to parse, not an integer or numeric()) may mean regex or
Len(spanincluding(trim(v),"0123456789")) EQ len(trim(v)) validation.
My examples are based on MSSQL semantics - for QoQ you’d have to use H2 semantics.
It was more documenting the different between the two engines.
For Lucee, the sql debug needs updating to show nulls instead of the datatype
and the documentation needs to be updated
Is this the only official differences guide between acf and lucee at the moment?
there is a much more substantial list here
@Zac_Spitzer I think based on what you’re saying Lucee is the less preferred approach.
I agree that if you’re using a cfqueryparam to populate a value you’re inserting or updating, it might be slightly more convenient for “” to be the same as NULL. But we have the null attribute for that purpose and it’s relatively easy to calculate, or to specify separately.
BUT if you’re using cfqueryparam in a WHERE clause, like you are, and it silently transforms to null, the query results will be invalid and there won’t be a clear indication why. In that case the ACF behavior of throwing an exception is exactly what I would want to happen.
My preference is for the ACF behavior - because it gives you a sane default with the options to do what you need it to do. In Lucee, the default could cause invalid query results, silently, and you’d have no way to tell queryparam to throw an exception instead, so now you NEED to do length checks on all your queryparams before running the query, and as you indicated, the debugging output doesn’t even help.
The appearance of things like IsNull() in CFML reinforces that in todays programming world, Null != “”, and I think this behavior is a step backwards.
Just my $.02
I agree , the acf behaviour is better, that said having <cfqueryparam value=“v” type=“integer” null=“auto”>,
which would be the same as null="#Not Len(Trim(v))#" would be nice
I ran into this issue recently and would like to revive this conversation, because in my opinion this behaviour needs to change. I spent a lot of time debugging this issue.
I have never tried running this in ACF as we use Lucee, and I totally didn’t expect that
<cfqueryparam> will silently turn empty value into NULL!
I am working with a codebase not written by me, and I agree there are approaches for checking the value before using it more thoroughly, but this behaviour is not documented and is counterintuitive. I would expect the tag to either throw an error or convert “” into a 0 in case of numeric cfsqltype.
<cfquery result="test"> INSERT INTO AdminUser (active) VALUES (<cfqueryparam cfsqltype="cf_sql_bit" value="">); </cfquery> <cfdump var="#test#">
This code inserts NULL into the DB. I don’t think this is the correct behaviour.
Should I file a bug?
I think you should file a bug Marianna. An empty string is not a valid value for a bit, integer so it should throw an exception. You should also note in the bug report that it is incompatible with ACF, even though that doesn’t matter in your case, it should give the issue a higher priority.
Which database are you working with?
I am using Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Zac, I found a bug that you submitted in 2017 that’s I think is the same issue, which is still in the backlog. I added my comment.