cfqueryparam

[Guest]

Have read cfqueryparam can cause problems when table structure is changed.

Has anybody seen this ?

If so, is there a way to use cfqueryparam but avoid the problem ?

[Owainnorth]

I have never once had an issue with cfqueryparams at all, certainly not on change of a table structure - as all they do is create bind variables I can't imagine they have anything to do with the column order. Queryparams are used for sending data *to* the database server, CF wouldn't even know the structure had changed until the data comes back.

Are you actually having an issue?

[Guest]

I'm not having the issue but have read about it.

[Adam Cameron.]

I'm not having the issue but have read about it.

Can you post a citation of this?

--

Adam

[Guest]

http://www.techfeed.net/blog/index.cfm/2006/4/14/CFQueryParam-problems-after-you-change-a-query

[Adam Cameron.]

OK, so back to your original question:

> If so, is there a way to use cfqueryparam but avoid the problem ?

Did you actually read the thread you just pointed us to? 😉  It kinda answers that question.

FWIW I got this a few times around about the time that thread cropped up, and it was indeed only when using SELECT *.  SELECT * is seldom an appropriate thing to do, so the solution we used was to stop doing SELECT * (and berate the developer who had written that code, as it was contrary to our coding standard).

--

Adam

[Guest]

Was hoping to learn to avoid the prob. completely.

[Joshua_Cyr]

CFqueryparam should be required. If you are not using them you really need

to start asap. As for the possible issue you asked about, the solution is

exactly as others pointed out. Do not do Select * from Table. (Disclaimer,

I do use that from time to time for very simple stuff and quick throw away

code.)

Instead select colA, colB, colC, etc

This will have other added benefits for you as well.

Other direction you could go is use CF9 built in ORM support. There is a

lot of powerful stuff there and changing table structure is quickly

implemented.

Joshua

[Adam Cameron.]

That thread is almost five years old (like... a coupla weeks shy of being five years old).

Have you checked to see whether it is still the case?  You might be inventing something to worry baoutt hat doesn't exist.

It's dead easy to replicate, just have a query with SELECT *, run it, then remove one of the columns from the table being queried (provided that specific column isn't actually referenced in the query SQL itself, obviously ;-).  Run the query again.  Does it error?

--

Adam

[Guest]

Will test that and if need to, will take out select *s as those queries get cfqueryparams put in.

[Adam Cameron.]

You should probably get rid of any SELECT * references anyway.  Just return the columns you need (which is almost never "all of them").

--

Adam

[ecobb]

The only thing I can think of that would possibly break something is if you changed a column's datatype.  For example, if you had a varchar column that you decided to make numeric, in which case that would break a query without cfqueryparam as well.

Thanks,

Eric Cobb
ECAR Technologies, LLC
http://www.ecartech.com
http://www.cfgears.com

[Dan_Bracuk]

Is there a problem that you are actually having?  Is there clear evidence that it is being caused by cfqueryparam?

[Guest]

I'm not having the problem, so can't blame cfqueryparam.

No cfqueryparams except in testing so far. Hoping to use them soon.