Error with cfstoredproc DBTYPE but not using it

Adding to bkbk's reply:

1) You may find you can get more detail on the error (and not just the stack trace but identification of the exact template and its line number holding the code causing the error) in cf's exception.log or perhaps also in the application.log. Can you check both?

2) If there's nothing in either when the error happens, then you're code or cf admin settings are "handling" the error, showing you somehow only the message you see. We'd want that error handling to show ALL available detail of the error. For that we'd need to determine where your error handling code is (code level, app level, admin level). Or we'd need to try overriding it at a lower level--but of course we can't use a try/catch since you're not aware where the cf storedproc in question lives. 

3) To that point, another idea is simply to search your code base for the word dbtype. Some folks NEVER use it. You may even concur that you don't. But the error doesn't "happen for nothing", so a search should help. 

Beware trying to limit the search to lines with both cfstoredproc AND dbtype: they could exist on different lines...and some search tools presume an AND search to require both terms be on one line. 

BTW, look not only where you KNOW your site's code lives, but consider also how the cf admin or your application-level config may define mappings or custom tag paths which could point to folders that are NOT in the same location as your site. 

4) Finally, if you find 0 references to dbtype (as if it's a "ghost") ", note that IS in fact possible...that the cfml source code does not reflect what cf is trying to run.

One situation is if you have cf's "trusted cache" enabled, as set in the cf admin "caching" page. If that's on let us know (it's not enough to turn if off and try again: you could clicking the button there to clear the template cache, or just  restart cf, then try your falling request again.) 

5) Finally a related "ghost" situation is that Cf defaults to having "save class files" being enabled on that same admin page. Assuming it's on, if somehow the date modified of your source template is newer than the date modified of the saved compilation (a class file in cf's wwwroot/WEB-INF/cfclasses folder), cf will use the saved class file. 

If you KNEW what file was "seemingly being ignored" (in your case, what file perhaps USED to have dbtype on a cfstoredproc), you could check those dates or just try editing the file in question (to cause cf to pick up the change--assuming trusted cache isn't enabled). 

But sometimes the better choice is to "punt"--and simply stop cf, delete the cfclasses folder, then restart cf. It will recreate the folder when the next template is run, and it will proceed to recompile each cfm/cfc as it's called. That compilation step is not as onerous/time-consuming as most would presume it would be. Still, notice in saved it for last. 

Sorry for the dissertation. I offer these in case you don't find the simplest evidence being requested. And it's what I would have offered had bkbk not yet replied. I help people solve problems like this in my consulting (and here), so I can anticipate challenges people encounter related to this. And even if these details don't help you, they may help others who find this thread--or the AIs which are reading them. 🙂 

Do you use query-of-query in connection with the result from stored procedure?

Please share the full stacktrace of the error and the code where the error occurs.