9.2 Parameters and Business Objects

When referencing a parameter twice within a query I recieve the error message below:-

Error:

Details:Failed to execute deployed method 'DataValue', using entity 'Grid1'. Item has already been added. Key in dictionary: '@Param' Key being added: '@Param'

parameter declaration:

Declared Parameter

Query:

Query

Error:

(please ignore parameter variable name. The error message is the same)

Error

This kind of reference could be accomplished in the previous version. 9.1

I will now have to create a parameter for each reference within the query?

Is this behaviour inteded in 9.2?

Find more posts tagged with

BPM

Comments

Jerome_Pearce

Yes, this is a new 'feature' in 9.2. I am not sure if I have seen it in 9.1.3 as well, in fact.

Brian Mellert

I didn't have that issue in v9.1.2.2 -- I created several BOs reusing the same parameter multiple times in the where clause.

These have been upgraded to v9.2.1.0 and they still work as well. (We didn't ever upgraded to v9.2.0.# so maybe we got lucky and skipped the issue.)

I just created a new BO to check to see if it exists in v9.2.1.0, I just created another/new BO using a single parameter twice. I have not deployed, but it is working without issue on the "Test" tab of the BO definition.

(My opinion, being unable to reuse parameters in a BO clause is very poor design and not logical, so hopefully its more than just a fluke I'm still working in v9.2.1.)

Jerome_Pearce

Yes, it is fine in 9.1.2. We moved to 9.1.3 on one system for Oracle client versions and Ajaz performance enhancements. I am fairly certain I saw it there, but we do this rarely so I cannot find it again.

Yes, it will be fine in the Designer, and deploy, but will fail at runtime.

Brian Mellert

OK, I've officially been burned by this now, and I'm much more angry about it than I thought I'd be. :smileymad:

It seems if you don't touch the BO, if a BO parameter was reused multiple times it seems to work fine.

If you touch it, this issue raises it ugly head ... and as confirmed by others, it doesn't show until after published.

In my case I have a report with 5 input parameters. Due to the type of data, we have services and an "other service". This forces a union of two queries to get one set of data. Additionally, the report input parameters are used in CASE statements in the query itself and due to other reporting requirements it also uses a WITH clause (SQL). This means I ended up from going from a parameter having to be defined once and used multiple times ... to having it defined separately 7-11 times. (paramA-paramG or to paramJ or to paramK). This means I went from having 5 input parameters ... to 60 input parameters with only 5 values.

I could create a view or stored procedure in the database, but this isn't a high-use BO and I don't like to create database objects for little benefit.

I believe I once saw a reply saying this is functioning as designed. If so, its rather poor design. Why should I have to create several separate parameters for a single input value? (Granted, this is a more complex query due to the unions and use of a where cause, but still ....) Since a single variable was able to be reused in a query logically, what was the functionality broken?

Richard Galt

This is a real problem for us as well. Duplicating the same parameter is time consuming.

Michael Illarietti

Somebody know if this is a known product defect and this behavior will be fixed in future release ?
Or this is a new 'feature' in 9.2. and it will still stay the same behavior?

Stuart White

The fix for this issue is being tested and is planned to be included in our 9.2.1.1 release. We'll confirm the release date for 9.2.1.1 in the near future.