> 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:322517 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
