Weird Alias problem

DEFINE VARIABLE chDataBaseList AS CHARACTER NO-UNDO INITIAL "C:\Users\jpalmer\Copy\ABL2DB\Schema Holders\commliv\commliv,C:\Users\jpalmer\Copy\ABL2DB\Schema Holders\docliv\docliv,C:\Users\jpalmer\Copy\ABL2DB\Schema Holders\Live\icmasliv,C:\Users\jpalmer\Copy\ABL2DB\Schema Holders\netsec\icsec,C:\Users\jpalmer\Copy\ABL2DB\Schema Holders\secure\secure".
DEFINE VARIABLE chAliasList AS CHARACTER NO-UNDO INITIAL "comm,docum,ICMAS,inteletrade,secure".
DEFINE VARIABLE chDataBaseConnectParams AS CHARACTER NO-UNDO INITIAL "-1|-1|-1|-1|-1".
DEFINE VARIABLE chSchemaDirectory AS CHARACTER NO-UNDO INITIAL "C:\Users\jpalmer\Copy\ABL2DB\Schema Holders".
DEFINE VARIABLE chSchemaFileList AS CHARACTER NO-UNDO INITIAL "commliv,docliv,icmasliv,icsec,secure".
/* Propath needed for compile */
DEFINE VARIABLE chPropath AS CHARACTER NO-UNDO INITIAL "C:\Users\jpalmer\Copy\ABL2DB\ICMAS\CLS,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\Core,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\ICODE,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\PCODE,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\TRIGGERS,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\WCODE,C:\Users\jpalmer\Copy\ABL2DB\ICMAS,C:\Users\jpalmer\Copy\ABL2DB\INENCO,C:\Users\jpalmer\Copy\ABL2DB\SECURE\ICODE,C:\Users\jpalmer\Copy\ABL2DB\SECURE\PCODE,C:\Users\jpalmer\Copy\ABL2DB\SECURE\TRIGGERS,C:\Users\jpalmer\Copy\ABL2DB\SECURE\WCODE,C:\Users\jpalmer\Copy\ABL2DB\ICMAS WEB DEV\ICODE,C:\Users\jpalmer\Copy\ABL2DB\ICMAS\ICONS".


    define variable mchCurrentDB as character no-undo.
    define variable mchLogicalDB as character no-undo.

def var lv-i as int no-undo. 

do lv-i = 1 to num-entries(chDataBaseList):

      mchCurrentDB = entry( lv-i, chDataBaseList ).
      mchLogicalDB = entry(num-entries(mchCurrentDB, "\"), mchCurrentDB, "\").
      connect value( mchCurrentDB ) value( entry( lv-i, chDataBaseConnectParams, "|" )).
      create alias value( entry( lv-i, chAliasList ) ) for database value( mchLogicalDB ).
end.       

propath = chpropath.

compile value("C:\Users\jpalmer\Copy\ABL2DB\ICMAS\PCODE\PLExportMaster.p").

Excuse the wonky formatting - just some code I cobbled together to prove the point. 

That's a good point. I'll give it a go. Although I get the same behaviour with different classes in the full application I'm using.

No get the same behaviour with the compile in a different .p.

The databases have the same physical and logical names which are different from the alias ones. The aliases must be setting correctly for it to get that far in the compile.

I'm going to create up a way to replicate the issue in a more easily reproducable way and log a support issue.

Using sports2000 I can easily reproduce the issue.[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/6746.brokencode.p:550:0][View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/3527.comp.p:550:0][View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/3252.compiletester.p:550:0]

Run CompileTester with all the code in c:\temp and the sports2000 database in c:\temp\sports2000. 

What's happening here is that in the brokencode.p the compiler gets confused due to the mixing of qualified & unqualified references:

for each Order no-lock:

 find s2k.Customer no-lock

   where s2k.Customer.CustNum eq s2k.Order.CustNum no-error.

end.

The first reference gets resolved to the logical database name (think of that as the first alias in the list of aliases for a given connection), making it a qualified buffer reference for sports2000.Order. That's a different buffer name than s2k.Order, which is why the compiler errors out a few steps later.

Makes sense Frank. Unfortunately it doesn't help my case! Using -ld causes other issues with Proparse and there are too many instances of the unqualified references in the code base to validly fix them in the time constraints I have.

Just to clarify, what you are seeing is expected and documented (look at the CREATE ALIAS statement, under the Notes section). The compiler is not getting confused. The use of aliases make the compiler create a reference to the table that is different from the unqualified reference. We have to do it because at runtime we do not know which db the alias will be pointing to and we can't guarantee they will be for the exact same table. Therefore, when you use aliases, you should always qualify the references.

And as for the CONNECT statement, the reason the connect would have to be in its own .p is because you can't reference a table and try to connect to the db in the same .p - when the .p loads, it needs to have the databases it depends on already connected. That's all.  So the code that James had with the connect and create alias in the same .p is just fine since there are no references to tables on that .p.

Thanks Fernando for clarifying. That's going to unfortunately cause some major issues for me :(

Tim, not its own .p, but at a higher level than the use.

I *think* that James and I may have figured out what we need to do to keep Proparse happy and so we should be able to handle this.   I guess the bottom line is that it is bad practice to mix qualified and unqualified references and it is, if anything, surprising that this hasn't caused other problems earlier.