OE Architect: "Unknown or Ambiguous Table"

KMoody

KMoody

Member
Progress: 10.2b SP7
OpenEdge Architect: 3.4.2.R342_v20090122-9I96EiWElHi8lheoJKJIvhM3JfVsYbRrgVIWL
OpenEdge OS: Windows XP Professional 2002 SP3
Server OS: SUSE Linux Enterprise Server 11


I’m trying to compile a few simple programs in OE Architect to verify that I can connect to the right database on the right server.

When I run the following program, the “Connected!” message appears, indicating that I’m connected to dbName:

IF NOT CONNECTED("dbName") THEN​
CONNECT dbName -pf P:\APPS\MYAPP\DBNAMERUN_102b.PF -S **** NO-ERROR.​
​
IF CONNECTED("dbName") THEN​
DISPLAY "Connected!".​
​
PAUSE.​

I then changed the program:

IF NOT CONNECTED("dbName") THEN​
CONNECT dbName -pf P:\APPS\MYAPP\DBNAMERUN_102b.PF -S **** NO-ERROR.​
​
FOR EACH LABOR WHERE LABOR.AG-DATE = 06/03/2013 NO-LOCK: ​
DISPLAY LABOR.​
END.​
​
PAUSE.​

When I ran the program, OE Architect returned the following error:

Unknown or ambiguous table LABOR. (725)​
** testing.p Could not understand line 9. (196)​

Using the Data Dictionary, I’ve confirmed that the table LABOR exists in dbName. If I’m connected to the dbName database, then why doesn’t the compiler recognize LABOR?
 
The CONNECT and the code that references the tables CONNECTed to have to be in separate files (and run in order, obviously).

I think this is because the runtime verifies that the LABOR table is accessible before running ANY of the code in the procedure, eg., it is making sure it can resolve LABOR before it executes the CONNECT statement.
 
Hmm, I wondered if that was the issue, but we have old Progress code that can CONNECT to a database and reference it within the same file. Is this separation a new requirement?
 
You can connect to a DB and reference it within the same procedure with dynamic queries. But if your queries are static your access code needs to be in a sub-procedure called downstream from your CONNECT. I can't quote 4GL history chapter and verse, but I'm not aware of a time when this constraint didn't exist.
 
AFAIK, it's been that way since time began, I believe it's baked into how they validate .p/.r code before running it.

It could be that your old code had a CONNECT that didn't actually matter, because the DB was connected anyway.
 
It could be that your old code had a CONNECT that didn't actually matter, because the DB was connected anyway.
Click to expand...

You're absolutely right. Turns out that our old programs assumed that they were connected to the appropriate DBs. I also found out that we could use CONNECT statements and database references in the same program only because they were dealing with two different databases - one connecting, the other one already connected.

Thanks for your help!
 
The reason for it is as simple as that:

As soon as you statically reference a database object in your code, when it gets compiled the database references and the CRC codes of referenced tables and indexes get compiled into the .r code. Whenever a .r code gets executed that has a database reference compiled into it, the referenced database need to be connected already - otherwise you will get an error message stating that the database is not connected an a STOP condition will be raised. Therefore you can't connect to a database and statically reference any object of it in the same program ( or class ).

But, you only need to authenticate ( with username/password in SETUSERID or the CLIENT-PRINCIPAL ojbect ) just before your code actually uses the database objects.

Heavy Regards, RealHeavyDude.
 
You must log in or register to reply here.
Back
Top