We have many scenarios in which a stored procedure is defined within MS-SQL as having optional parameters, and since our application has never passed these to the calling stored procedure, these parameters have been executed as per their default values within the SQL. For example
Code: Select all
CREATE PROCEDURE dbo.VerifyClaim @ClaimNo Integer, @VerifierID Char(10), @Silent Char(1) = 'N' AS ...
We have been using SDAC for all new work for a few years (quite happily) until a decision was finally made to move all the old BDE code to SDAC. Since we use our own component classes, we simply changed our ThslStoredProc from having ancestory of TStoredProc to TmsStoredProc. this has worked sucessfully except for default parameters as described above.
I have been able to determine that the problem is due to TmsStoredProc always calling sp_procedure_params_rowset prior to execution. The result is used to generate the parameter list which is used to construct the SQL command. It seems that this varies to the BDE which simply takes the parameters as recorded in the DFM and constructs the SQL from this list. Our DFM params list only lists the required parameters and the code only passes these to MS-SQL. The net effect is that instead of not passing these parameters, they are being passes as NULL, which is resulting in incorrect operation.
Code: Select all
in SDAC: EXEC dbo.VerifyClaim @ClaimNo = 10, @VerifierID = 'ben', @Silent = NULL in BDE: EXEC dbo.VerifyClaim @ClaimNo = 10, @VerifierID = 'ben'
NB: We have several thousand stored procedure components, of which several hundred are using optional parameters. We need a solution that will solve this problem without change to our code base or our stored procedures.
HAMB Systems Ltd.