Hello Set,

>> As I understand, with inner joins FB for some reasons puts the
>> stored procedure at the first place (as a left dataset), and then
>> joins the rest tables with it. Since the stored procedure uses
>> fields from the "following" tables, it doesn't "know" the value of
>> those fields when executing. Outer join "forces" the join order.

SET> Does this mean that preventing the PS.Z_Personal_ID index from being
SET> used like
SET> SELECT PS.Z_Personal_ID, HMA.O_Personal_ID
SET> FROM T_Personal_Salden PS
SET> JOIN P_Hole_Makler_Adressen(PS.Z_Personal_ID) HMA ON
SET> HMA.O_Personal_Id = PS.Z_Personal_ID+0
SET> could work as well?

Originally in my case, it was stuff like
...from Rooms r
join GetRmCosts(r.ID, :UID, :DoAll) rmc on 1=1...
and GetRmCosts didn't return the value of r.ID as its output
parameter. I rewrote the SP, so it returns ID now; and the stuff like
...from Rooms r
join GetRmCosts(r.ID, :UID, :DoAll) rmc on rmc.RmID=r.ID+0...
doesn't work for some reasons either.

SET> Or maybe you would have to do something like
SET> SELECT PS.Z_Personal_ID, HMA.O_Personal_ID
SET> FROM T_Personal_Salden PS
SET> JOIN P_Hole_Makler_Adressen(PS.Z_Personal_ID) HMA ON
SET> HMA.O_Personal_Id = PS.Z_Personal_ID
SET> where PS.PK < 1000000000 //a very high number

Left outer join works quite well for me. But it's a workaround that
took some time to find out (and the strange error message messed
things up a little).
I don't know about Christian's case (he is the original poster).


--
Best regards,
Pavel Menshchikov
http://www.ls-software.com