Weird things happen when using .cfc function arguments

Have you checked the logs to see what (if anything) else is being reported
back about this?

Can you check what's going on on the Oracle - am guessing it's Oracle from
the "CONNECT BY PRIOR" - box @ the time? I presume you can set it to log
all SQL or JDBC activity?

Are you certain (absolutely ~) that arguments.jpRunNum contains 32144809,
for the purposes of the test that's failing?

What if you factor the query out into a CF template and run these tests:

1) as is in your example
2) change 32144809 to use a <cfqueryparam>, but still hard code the value
to 32144809.
3) set a variable to 32144809, and use the variable as the value of the
parameter.

From what you're describing, it seems like your query is getting in a loop,
which with this sort of thing can be down to giving the CONNECT BY PRIOR a
bung value.

--
Adam

Depending on what database server you're using, and what driver, changing a static value to a <cfqueryparam> can change the statement sent to the database from a static SQL statement to a prepared statement. This can drastically change the query plan, thereby changing execution speed.

What happens if you try to use <cfquryParam value="32144809"
cfsqltype="cf_sql_integer">?

Does the value '3214809' fit inside an SQL integer value, it seems a bit
big to me. You may need to be using cfsqltype="cf_sql_bigint".

Get the query to work in a .cfm page with cfqueryparam first. Then any problems you subsequently have will be a result of your function call.