can bad coldfusion coding affect on database to go down?

[sankalpah]

I am doing all coldfusion coding part. I am given readymade queries.(stored procedures written in database.) I am accused of writing bad code which made database go down. I am not understanding if i am given queries or stored procedures & I am not directly making any requests to database no <cfquery> tag then how can coldfusion code make database unavailable for some time? because of some timeout or something.
All examples of it all welcome.
thank you.

[Dan_Bracuk]

If your query is going to return too many records, it might bring down the database (not that I've ever done it, I, um, read it in a book).

If you are sending arguments to stored procedures, one way to do it is to send too short a string. Zero length strings are espeically bad.

Let's say the stored proc includes something like
and some_text_field like '%your string goes here%' and you send it an empty string.

Having a start and end date too far apart could have the same effect.

[paross1]

This is a rather easy accusation to levy but hard to prove unless your DBA has specific information as to what he/she believes is the problem. Perhaps you are merely guilty of accessing poorly written stored procedures that lack the inclusion of minimum protections for the database. For example, nearly ALL of my PL/SQL stored procedures are written to "protect" the database from invalid data so that I do not have to depend on the front end application programmers to screen for valid parameters, etc. Also, are they written to adequately handle exceptions, including the return of status messages back to the calling program, or do they just die and allow database exceptions to go unhandled, crashing your ColdFusion page?

Are you including procedure calls involving large sets of data within loops, etc?

I would insist on more information than “You must be writing bad code…”, since that accusation can work both directions. I would say, since they control the SQL, the ball would be in their court to prove that what you are doing is causing "the problem", whatever that is.

Phil