Rocket U2 | UniVerse & UniData

ROCKETEER Neil Morris posted 04-19-2023 09:04

Has anything changed on the UniVerse server side? I'm not real familiar with the ODBC side of things but the UniVerse part of the error message indicates a dictionary I-type is involved which is attempting to call a globally cataloged BASIC program. And the program "*PAID.AR.CALC012" is not currently in the catalog space.  Executing the MAP command at TCL on the UniVerse server will display the contents of the global catalog space.

Karl Diethrick posted 04-19-2023 09:11

Thanks @Neil Morris 

I am only familiar with the ODBC side and not any of the UniVerse tools.

If I were to contact the owner and administrator of this UniVerse system, how would he get the BASIC program into the global catalog space?  In other words, how can I query the tables involved without getting this error?

ROCKETEER Neil Morris posted 04-19-2023 09:23

Hi Karl,
I'm guessing that a BASIC program named PAID.AR.CALC012 exists in a program file on the server. For example, if it were in the BP program file and already compiled, adding it to the global catalog space could be done with a command like the following. This would be done the account where the program file resides.

>ICATALOG BP *PAID.AR.CALC012
"*PAID.AR.CALC012" cataloged.
>

Hope that helps.

Thanks,

Neil

Karl Diethrick posted 04-20-2023 09:10

Thanks again @Neil Morris 

That makes sense to me.  However, I contacted the administrators of the Universe U2 system where these tables live and they weren't sure what I was talking about.

What I don't understand is why this PAID.AR.CALC012 program causes the error with certain tables?  Is that because one of the columns in the INVOICE table relies upon that calculation?

Even if this were true, doesn't this indicate a bug in the latest U2 ODBC drivers?  If it works in Microsoft Query via Excel, why does the driver error out when using other applications?

ROCKETEER Jonathan Smith posted 04-20-2023 10:07

@Karl Diethrick 

In UniVerse files (what you refer to as tables) you can have fields (which you refer to as columns) that are virtual fields, that is, they do not physically exist in the file. They are a field derived from other information or as a result of a calculation. The message you see relates to one of these such fields and that it uses the program PAID.AR.CALC012 to perform to get it's result. The message informs you that the program is not cataloged (or missing) in such a way that it can be accessed in the account you are connecting to in order to run the query.

When you connect to the UniVerse server via ODBC you connect to an account, the error message you see when running the SQL query would also be seen from users within UniVerse in that account if they tried to use the native querey language and attempted to report on the fields (columns)  that rely on being able to access the PAID.AR.CALC012 program.

This is not a bug with the U2 ODBC driver, it is expected behaviour reporting that something, in this case a cataloged program defined with the field (column) definiton, cannot be accessed from that account.

Karl Diethrick posted 04-20-2023 10:24

Thanks, this is helpful @Jonathan Smith 

But the question that remains unanswered is: why can I see all fields in the INVOICES file when using Microsoft Query in Microsoft Excel, but when using any other tool with the SAME ODBC driver and SAME credentials, I get the error?

One might argue this is a Microsoft question, and I have opened a thread there as well.  https://learn.microsoft.com/en-us/answers/questions/1249314/odbc-connection-to-universe-u2-data-throws-excepti?page=1&orderby=Helpful#answers

However, it seems to me that the Rocket U2 Universe ODBC driver may not be doing something that it needs to be doing in certain situations.  Perhaps it is compatible with older tools, but is missing something that is needed for newer applications?