I have an error that keeps popping up in my application log file every now and then.

"Error","jrpp-2297","09/30/09","07:40:07","appname","Invalid data  for CFSQLTYPE CF_SQL_BIGINT. The specific sequence of files included or processed is: E:\inetpub\wwwroot\a\viewReport.cfm, line: 56 "

Is there any way that I can trap all parameters passed to this page via the form so I can see why that specific value is failing? When I try it from the website it processes fine.


+3  A: 

If you want to do some longer term watching of the data for this form, then you can use cfdump with some optional parameters to keep an eye on things:

<cfdump output="fullpathtoyourdumpfile" format="html" var="#FORM#">

If you want a plain text dump instead of the normal fancy HTML one:

<cfdump output="fullpathtoyourdumpfile" format="text" var="#FORM#">

The fullpathtyourdumpfile should be the fully qualified path (including drive letter if using Windows as your CF platform) to a file, including file name. Examples:


Use .txt for plain text dumps and .html for the HTML version. If you use the HTML version, you should be able to use remote file retrieval or have the directory mounted to see the contents.

In addition, you need to make sure that every directory listed exists and is read and writable by the user running ColdFusion.


For CFMX7, try this workaround:

<cfloop list="#FORM.FIELDNAMES#" index="key">

<cfoutput>#key# ----> #evaluate(key)#<br/></cfoutput>

Tony Miller
Thanks Tony, but unfortunately I am on CFMX7 and the output option only for CFMX8. Any other suggestions?Thanks!
For CF7, just do the cfdump exactly the same, but wrap it in cfsavecontent and use cffile to write the file.
Peter Boughton
Also, when looping through Form (or any scope) instead of #evaluate(Key)# do #Form[Key]#
Peter Boughton
Oh, and one more point - you can (and should) always use forward-slashes in paths. Yes, even on Windows. Doing c:/tmp/file.html works fine in Java-based apps.
Peter Boughton

If you are getting the error so intermittently you cannot make it happen you can capture the contents of the cfdump to a variable and then log that full html of the dump. Then you can grap the contents of the log line and put it in a static html file and view the cfcatch object as it would have been presented if you were the one who generated the error.

To do this you will need to use cfsavecontent.

<cfsavecontent variable="dumpoutput">
 <cfdump var="#cfcatch#" />
<cflog file="cfcatchdumps" text="#dumpoutput#" />

After doing this you wait patiently for the next error and then grab the contents of one line from the log file(it will be a long line, but it doesn't have any carriage returns, so it is somewhat easy ti grab), paste it into a html file and view it. This will give you some insight into what the error was with all of the tag context detail and stack traces.

Caveat: this is going to generate a lot of data to a log file, perhaps as much as 20-40K per error, this is not a big deal in a development environment and is probably worth the insight if happening very intermittently in production, but um, this is certainly not a thing I would leave anywhere for long term production usage. :)