[Stackoverflow] [Progress OpenEdge ABL] OpenEdge dynamic buffers... how do I avoid error 7328? ("unambiguous buffer field/reference for buffers known

Status
Not open for further replies.
A

Allan Green

Guest
Althogh I've been supporting (and extending) a legacy OE application for 10 years plus, I've never before been forced into the scary world of dynamic buffers... However, my luck has finally run out.

Let me start by saying I cannot believe how opaque the little OE documentation I could find is... the only Progress guide seems to be in the online documentation for v10.2 (thanks to the contributer to one of the forums for even that snippet.)

Anyway, this should be almost trivial. Except that it doesn't work;

Code:
DEFINE VARIABLE hFileBuffer AS WIDGET-HANDLE.
DEFINE VARIABLE hFieldBuffer AS WIDGET-HANDLE.

DEFINE VARIABLE cWhere AS CHARACTER.
DEFINE VARIABLE hQuery AS HANDLE.

CREATE BUFFER hFileBuffer FOR TABLE "_File".
CREATE BUFFER hFieldBuffer FOR TABLE "_Field".

CREATE QUERY hQuery.
hQuery:SET-BUFFERS(hFileBuffer).
hQuery:ADD-BUFFER(hFieldBuffer).

cWhere = SUBSTITUTE(
   "FOR EACH _File " +
   "         NO-LOCK, " +
   "    EACH _Field " +
   "    WHERE _Field.File-recid = _File._File-recid " +
   "          NO-LOCK"
   ).

message cWhere.
pause.

hQuery:Query-PREPARE(cWhere).
hQuery:Query-OPEN().

DELETE OBJECT hQuery. 
DELETE OBJECT hFileBuffer.
DELETE OBJECT hFieldBuffer.

ASSIGN hQuery = ?
       hFileBuffer = ?
       hFieldBuffer = ?.

The output from "message" is (after removing redundant spaces):

FOR EACH _File NO-LOCK, EACH _Field WHERE _Field.File-recid = _File._File-recid NO-LOCK

which looks fine to me.

However I then get:

_Field File-recid must be a quoted constant or an unabbreviated, unambiguous buffer/field reference for buffers known to query . (7328)

I just cannot see what is ambiguous about "_Field.File-recid" or "_File._File-recid". Or am I missing something? (I should add that the equivalent works in good ol'-fashioned static OpenEdge!)

Hoping someone wiser than I can advise,

Allan.

Continue reading...
 
Status
Not open for further replies.
Top