DB dip

[williams]

Hello,
In one of my strategies I am doing a db dip using a dap associated with a db server. I recently upgraded the dbserver to a version 7.5 from 7.2. My intention was to use the dap with the upgraded 7.5 dbserver. In CME, I am able to remove the old 7.2 dbserver and put the new one in its place. When I do this, the dap is automatically updated in the strategy.

when I test my email routing, I can see from the logs that the db dip is not working properly. It doesn't go out the green port in the strategy, but the red one.

In the logs I am seeing this error message" formal parameter" interactionid' was defined as OUTPUT but the actual parameter was not declared OUTPUT". I have checked out the stored procedure and the interaction id is indeed not defined as OUTPUT, which is correct.

When I put the old dbserver back it works ok. It doesn't seem to work with the new 7.5 db server for some reason.
Does anyone have any ideas?? I am using windows 2K,  mssql

Thanks

[K]

Not sure what version of DB Server you're running, but from the release notes:

Release Number 7.5.000.10 [11/16/07] – Hot Fix
Corrections and Modifications
This release includes the following correction and modification:

For MS SQL Server database engines, DB Server now correctly handles named parameters when calling stored procedures. Therefore, a procedure can be called with its parameters in any order, and parameters using default values can be omitted.

Previously, when a stored procedure was called with the order of the parameters different from the order specified during stored procedure creation, or with some parameters using default values omitted, the execution of the procedure would produce either an incorrect result or fail completely.

================
Also:

Release Number 7.6.000.08 [02/14/08] – General
Corrections and Modifications
This release includes the following corrections and modifications that were made between the initial release of 7.6 and this 7.6 release:

For MS SQL Server database engines, DB Server now correctly handles named parameters when calling stored procedures. Therefore, a procedure can be called with its parameters in any order, and parameters using default values can be omitted.

Previously, when a stored procedure was called with the order of the parameters different from the order specified during stored procedure creation, or with some parameters using default values omitted, the execution of the procedure would produce either an incorrect result or fail completely.

(ER# 173530495)

======

[williams]

Interesting. I will look into this. Maybe I need to remove some of the parameters in my store procedure now that it doesn't matter with 7.5.

anything else let me know.
Thanks

[victor]

Oh, boy, I think RN is pretty up to the point on this one. Just a reminder: people, let's not just copy the documents (even they are generically available). Next time, please  quote a piece of RN and not just paste-n-copy of the whole document.

Your friendly internet policeman