Error Error 8030

Mady

Member
Hello to All members,

Can you please advise on how to resolve below error ?
This file tt_ord.i exists in two places in my E drive and and I have already verified that number of fields is same in both the files. But still I am getting this error.

1643835019105.png

May be this is related to above error. For example - I have two .Ps --> ABC.p and DEF.p
I need to access a table "itemcust" in DEF.p from different database. So what I did is --> wrote CONNECT statement in ABC.p and from this I am calling DEF.p
During compilation I get below error.

Unknown or ambiguous table itemcust. (725)
** .\temp\DEF.p Could not understand line 109. (196)
Compiling .\temp\DEF.p ...error. - Compile Time = 00:00:00


Not sure why I am getting this error, when I have already given CONNECT statement in the parent file ABC.p
Please suggest.
 
Last edited:

Ashwani Mishra

New Member
Your temp-table has different number of fields in different piece of code. Compilation of both involved procedures will fix this issue.

Follow below post for more information

 

Mady

Member
Thanks, but I have checked that post.
This file tt_ord.i exists in two places in my E drive and and I have already verified that number of fields is same in both the files. But still I am getting this error.
I am unable to do a full compile due to below error, which I have explained in my post.

Unknown or ambiguous table itemcust. (725)
** .\temp\DEF.p Could not understand line 109. (196)
Compiling .\temp\DEF.p ...error. - Compile Time = 00:00:00
 

Ashwani Mishra

New Member
Connect statement in Abc.p will not connect to database in compile time. Connection to db will be done in run time when you use connect statement.

That’s a reason you are getting unknown and ambiguous table table itemcust.

Connect db whichever is required before you start compiling both procedures. Also make sure to use correct propath.
 

tamhas

ProgressTalk.com Sponsor
For starters, the include file should not be in two places ... that is asking for exactly this kind of problem.

Re the connect, note that you cannot connect to a database and access the database in the same procedure. You need to connect to the database and then run another program and access the database in that other program.
 

Mady

Member
For starters, the include file should not be in two places ... that is asking for exactly this kind of problem.

Re the connect, note that you cannot connect to a database and access the database in the same procedure. You need to connect to the database and then run another program and access the database in that other program.
Actually, I am not doing this in the same procedure. To be precise - I have two files "order.w" and "fill.p". I have given the connect statement (connect value("-db sox -N tcp -H sst-aix-test -S 8100").) in "order.w" and I am accessing table item-cust from sox database in "fill.p". I believe as per Ashwani's response connect statement will not connect in compile time and that may be the reason I get "Unknown or ambiguous table itemcust. (725)" during compilation of "fill.p".

I am just accessing item-cust in fill.p through FIND FIRST. I am thinking of trying the same, but using dynamic query instead.

Is there any better approach to accomplish the same ?

Thanks.
 

tamhas

ProgressTalk.com Sponsor
Well, obviously, to compile fill.p you have to be connected to the other database.
Have you tried putting a test in fill.p to verify that you are connected at run-time?
FIND FIRST is almost certainly the wrong thing to be doing.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
It looks to me like you have two separate problems. They should really be separate threads.

The error 8030 in your screenshot is about a temp-table passed as a parameter, from somewhere to somewhere else. An ABL client to an App Server? Do you know? This error has nothing to do with the database(s).

Error 8030, from ProKB:
Parameter number (table <table name>) mismatch. Has <field#> fields - client schema has <fields#> fields. (8030)

Temp-table parameters match only if they have the same signature. An example of nonmatching temp-table parameters: The caller's temp-table signature is: {char, int, char}, and the called procedure temp-table signature is: {char, char, int}.
If the mismatch is between a non 4GL client (Java or ActiveX) and AppServer 4GL code, then the typical reason for the mismatch is a modified 4GL temp-table without client proxies rebuilt.

This file tt_ord.i exists in two places in my E drive and and I have already verified that number of fields is same in both the files.
Those files may not even be a part of this application. This really doesn't tell us anything without knowing the compile propath(s).

Presumably, you are implying that each of these clients has its own compile with its own propath and each is using a different version of an include with the same name. (That would defeat the purpose of using an include file for a shared definition, but that's a separate conversation.) Also, you say that the same number of fields are in the temp-table definitions in both includes. But according to your screenshot, the compiler says that one temp-table definition has 114 fields and the other has 115 fields. I know which one I believe.

We can really only speculate without knowing more about these clients. Read the 8030 description above. Are they ABL GUI/CHUI clients? App Servers? Open Clients? Do you need to generate client proxies? Does each have its own code or do they share code? Right now you don't know which includes are being used on each side.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Regarding your database-related compile error, you said:
I have two .Ps --> ABC.p and DEF.p
I need to access a table "itemcust" in DEF.p from different database.
Ok.
So what I did is --> wrote CONNECT statement in ABC.p and from this I am calling DEF.p
As @Ashwani Mishra already told you, that won't work. Your compile ABL session needs to be connected to the required database(s) when it executes the statement that looks like compile DEF.p. (or fill.p or whatever.p). The compiler builds each compile unit separately. It doesn't have the context to know that the run-time caller will be ABC.p and it will have successfully connected to the correct database at run time.

I am just accessing item-cust in fill.p through FIND FIRST. I am thinking of trying the same, but using dynamic query instead. Is there any better approach to accomplish the same ?
Rather than refactoring in the hopes that it will be the silver bullet that makes a compile error go away, it is better for you to understand why you have that error, and fix the root cause. You don't need to change your code (as far as I am aware), you need to change your compile process. If your code references objects in a database, then your compile session must already be connected to a database with the appropriate logical name and schema version.
 

Mady

Member
Sure, I will quickly focus on the Error 8030 for now and will try to find out the spot where the system encounters with the discrepancy in number of fields. It happens during the appserver connect call below, and I get that error 8030. Will get back real quick.

RUN fill.p ON SERVER pserv TRANSACTION DISTINCT
(INPUT Qtext,
INPUT iRecordLimit,
OUTPUT TABLE tt_ord,
OUTPUT fiNum,
OUTPUT lRecords) NO-ERROR .
 

Mady

Member
I found two concepts, which seem to be related to the error 8030, below snapshots. By looking at the error, the procedure is getting executed in an appserver instance and may be there the tt_ord has 114 fields.
To find the appserver propath, I checked ubroker.properties and got below path. But I could not find the respective .P at these locations.
{&G_APP_SERVER_CONNECT} cConnect values --> "2600 -H dsc-aix-dev - AppService twlappsrv -S 7182"

I will be researching more, but your inputs would really help here.

# Default AppServer for Dynamics
[UBroker.AS.icfrepos]
PROPATH=.;D:\dlc100b\tty\dynamics;D:\dlc100b\tty;D:\dlc100b;D:\dlc100b\src;@{WinChar Startup\PROPATH};@{WorkPath}

1644010106399.png

1644010139754.png

1644011137347.png
 

Stefan

Well-Known Member
You are connecting to an AppService called twlappsrv on server dsc-aix-dev and then showing the propath of an AppServer called icfrepos?

You need to get to server dsc-aix-dev, look at the propath in the ubroker.properties on that machine and then compare the sources on that machine with your local sources.

Some form of source control is also lacking?
 

Mady

Member
I checked within my team and got below instructions in a saved document.

--Put the latest tt_ord.i at /twl/cust
--Do a TWL compile of the appserver code
--stop Appserver
--restart Appserver

But, I am unable to query the appserver using "asbman -name twlappsrv -query" on dsc-aix-dev. Getting error "Unable to find twlappsrv (8281)". I am using the correct name though.

1644337527088.png
 

Stefan

Well-Known Member
But, I am unable to query the appserver using "asbman -name twlappsrv -query" on dsc-aix-dev. Getting error "Unable to find twlappsrv (8281)". I am using the correct name though.
Do you have multiple Progress OpenEdge installations on dsc-aix-dev? If so, each has its own AdminServer with its own ubroker.properties file, listening on its own port. The default is 20931, but as soon as you have a second AdminServer running, they both cannot listen to the same port. You can ask asbman to listen to a non-default port with -port 2093x
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Not that I don't want to help you, but you've been at these problems since last Wednesday afternoon. It sounds like your team knows what to do but isn't actively providing much assistance. My sense is that someone in your organization who knows the solution could spend some time with you and get this resolved more promptly.
 
Last edited:

Mady

Member
Totally Agree with you Rob. Actually I just wanted to try figuring this out. I had a discussion within my team and got it resolved within a day. There was some issue within the properties file, it had to be updated and environment restarted. Thank you all so much for providing valuable inputs and knowledge. :)
 
Top