While I can't spot what is wrong here, I can verify that I do this in my
procedures a LOT, and I have never had an issue. I currently and have
always used Firebird 1.5* for Winders and Loonix.

Jason

Pavel Menshchikov wrote:

> Hello Christian,
>
> CG> The example can be simplified to a simple join of a table and a
> CG> selectable stored procedure.
> CG> This does not work:
>
> CG> SELECT PS.Z_Personal_ID, HMA.O_Personal_ID
> CG> FROM T_Personal_Salden PS
> CG> JOIN P_Hole_Makler_Adressen(PS.Z_Personal_ID) HMA ON
> CG> HMA.O_Personal_Id = PS.Z_Personal_ID
>
> CG> Error message:
> CG> ISC ERROR CODE:335544348
> CG> ISC ERROR MESSAGE: no current record for fetch operation
>
> CG> But with a left outer join, it does work:
>
> CG> SELECT PS.Z_Personal_ID, HMA.O_Personal_ID
> CG> FROM T_Personal_Salden PS
> CG> LEFT OUTER JOIN P_Hole_Makler_Adressen(PS.Z_Personal_ID) HMA ON
> CG> HMA.O_Personal_Id = PS.Z_Personal_ID
>
> CG> So I have a workaround for my problem, but it would be nice if someone
> CG> could explain why the second query works and the first does not.
>
> I had the same problem. And my workaround was the same.
> 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.
>
> I hope that FB 2.0 will fix it: I mean the situation
> -----
> ...from Table
> [inner] join StoredProc(Table.Field) on <condition>...
> -----
>
>