I just found this thread about parameters in stored procedures: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=10200&StartAtMessage=0&#78382

This was quite interesting.

We experience similar problems, but in this case the actual procedure doesn't even show up. It is also a case with two different packages containing procedures that have identical names (and in this case also an identical signature - list of parameters). The problems occur in version 2.5 as well as 2.6 (Build Final, June 6th 2008 ).

Database driver is Oracle 10g DBDriver (2.6.06062008 ). I also tested with Oracle DBDriver using MS Oracle (2.5.08272007), same results there.

This is really not a case of overloading procedures. To overload a procedure, the two(+) versions of the proc must be defined within the same package. The package name is like a namespace, there is no ambiguity whatsoever between two methods in different packages even if the method names and signatures are identical.

It is really weird - and in my opinion this must be a bug in LLBLGen. It is quite hard to figure out how to make sure the necessary procedure actually shows up. Sometimes it is there, sometimes it is not I needed to refresh the catalog now to include some newly developed packages, and then this procedure disappeared. Neither one of the two packages had been significantly changed since the last time we refreshed the project. For the problematic package, only two procedures (out of totally 6) now show up. But both of these procedure names do also exist in another package, where they also are defined with the same signature. For at least one of the procedures that is "lost", it doesn't appear for any of the two packages that declare procedures with that name.

So it isn't consistent, and therefore is difficult to reproduce in a simple test case.

I was able to make a very small test case which demonstrates the problem with missing parameter definitions in llblgen however. First I created a new schema for the purpose of testing, so no other objects are owned by the schema. Then I create two packages; "a" and "b". Both implement a function "testfunc". "a" also has a procedure testproc.

If the testproc procedure is included in a, then all arguments for b.testfunc are generated in llblgen. However, if "testproc" is not included (as below), b.testfunc appears to have no arguments. This is true both for version 2.5 and version 2.6.

create or replace package B is
  function testfunc(aparam IN varchar2) return varchar2;
end b;
/
create or replace package body b is
  function testfunc(aparam IN varchar2) return varchar2 is
  begin
    return lower(aParam);
  end;
end b;
/

create or replace package A is
  function testfunc(aparam IN varchar2) return varchar2;
 --procedure testproc ;
end a;
/
create or replace package body a is
 function testfunc(aparam IN varchar2) return varchar2 is
 begin
  return upper(aParam);
 end; 
 /*
 procedure testproc is
 begin
 NULL;
 end;
 */
 end a;
/

This is a rather big problem for us, can you please look into it and fix this bug?

with regards, Helene

Procs are named as package._procname_ if they're in a package, so all should show up.

It might be other issues are found with the proc, does the ApplicationOutput dialog show anything?

We'll look into it if we can reproduce it.

I get in the application output window

RefreshCatalogs::Parameter 'RETURN_VALUE' at position 0 is already present in stored procedure 'PackageA.TESTFUNC', probably due to overload in package (not supported). Skipped
RefreshCatalogs::Parameter 'APARAM' at position 1 is already present in stored procedure 'PackageA.TESTFUNC', probably due to overload in package (not supported). Skipped

So there's something odd going on. The B func indeed doesn't have a parameter, likely due to the fact that the error above is reported.

This bug must be present for a looooooong time (years) in the code, the situation of same proc / different package apparently never occured. Looking into it.

(edit) Found it. Silly issue. Will fix it.

Please use the attached updated driver for ODP.NET 10.2, 10g

It's really an edge case, as the list of parameters retrieved from the DB had to have the procs enlisted directly after eachother, if another proc's parameters was in between the two, it would work.

That is really great, I will test that now Thanks a lot.

The dll you attached seems to be version 2.6, can this same dll be used also from LLBLGen 2.5? We haven't upgraded to 2.6 in the production environment yet, I have just installed it to do some initial testing.

With regards, Helene

Helene wrote:

That is really great, I will test that now Thanks a lot.

The dll you attached seems to be version 2.6, can this same dll be used also from LLBLGen 2.5? We haven't upgraded to 2.6 in the production environment yet, I have just installed it to do some initial testing.

With regards, Helene

No it can't be used with 2.5. If you have to use it in v2.5, I've to apply the patch there too and attach that. I'll attach the v2.5 build a.s.a.p.

(edit) See attached dll.