Is there a limit on the number of parameters in TStoredProc?

Is there a limit on the number of parameters or the total size of the parameters in the TStoredProc ExecProc call?

A system is currently running that still uses BDE to connect to Oracle and the recent change in the number of parameters for the package procedure, as they began to create access violations. The number of parameters is now up to 291, and AV is created in the ExecProc TStoredProc call.

If we remove one parameter from the list (any parameter does not have to be a specific parameter), the ExecProc call works fine.

I am debugging the code, and access violation is caused by the TStoredProc.BindParams procedure in DBTables.pas. I have several hours installed, one of which is SizeOf (FRecordBuffer), and when I perform this procedure, the value is 65535. This is MaxWord (Windows.pas). I do not see any restrictions in DBTables code.

The column is TStoredProd.ExecProc -> TStoredProc.CreateCursor -> TStoredProc.GetCursor -> TStoredProc.BindParams, and an access violation is triggered in a for loop that iterates through FParams.

Thank you in advance, we need to find something that we can define so that we can be understood.

+4
source share
1 answer

I donโ€™t understand Oracle SQL at all, but since you support this thing, I would see if I can change the call with all these parameters to one insert in a new selected table (with so many columns plus the primary key of autodial) and change the stored procedure to take this key as input and call the values โ€‹โ€‹from this new record to do its job. It may just be a little faster than finding out what is the maximum number of parameters and trying to find a fix there. (Although this is a bit strange number, if not in force 2, it may well be 291 ...)

0
source

All Articles