LOL I am glad that you asked about the VARCHAR auto increment, Dave. It is an interesting story (everybody grab some hot cocoa, please): Well, (most) iMIS tables have a VARCHAR identity field which need to auto-increment like an integer. To achieve that, there is table which stores the "next" ID value for these tables. So, whenever an INSERT is done on an iMIS table, this special table with the "next" ID values have to be updated to reflect what the "next" value is for the table which just got the INSERT statement. To make life more interesting, some iMIS tables have triggers on them so that the special table gets automatically updated, but others don't. Make sense? Probably not. But well, that is how it is done.
As for the cached SQL statement, I think I understand what you mean now. So it is basically like changing the accepted parameters of a CF function--it used to take INT1 and INT2, now it wants VARCHAR1 and INT2, and that CF function happens to be in APPLICATION scope or other persistent scope. So things break until you can refresh the function. Hmm... but I still can't imagine how it happened to my code since our table schema has not changed. Well, I guess my lessons here are: 1) Don't try to be cute with CFqueryparam, always use the same data type as the receiving table column; 2) Make sure the column which holds the same data has the same data type across tables. But still, it is interesting to ponder whatever happened to my data, and why, of all things, everything got to be 521636a. Just another thing to think about on the metro. On Thu, May 14, 2009 at 2:39 PM, Dave Watts <[email protected]> wrote: > > > 2. The incoming data is supposed to be for an ID column, which is of > VARCHAR > > data type in the database, and it auto increments. It is not designed to > be > > hexadecimal, so I can't imagine the translated value standing for any > > hexadecimal either--well, at least there is no instruction on either the > CF > > or MSSQL side which tells it to convert into hexadecimal. > > > > Adding to the confusion of course, is that this ID column is sometimes > > VARCHAR and sometimes INT in different tables--probably not the best > > practice. We have an archaic system (iMIS) and it has this ID as > VARCHAR, > > but elsewhere, in built-in-house systems sometimes it is INT. > > What does it mean for a VARCHAR to autoincrement? > > > Regarding Brad's comment: I am intrigued by the theory of corrupted > cached > > SQL statement... What exactly does that mean? How does corrupted > statements > > get cached? And if it was corrupted, how/why did it run before with no > > issues? Did something happen that made the corrupted cache stop working? > > You run a valid SQL command, you change the schema in such a way that > it would no longer be valid, and you attempt to rerun the same command > using a cached execution plan. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction at our training centers in Washington DC, Atlanta, > Chicago, Baltimore, Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more informati > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:322520 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
