HELP, HELP, HELP - GLOBAL TABLES PROBLEM

hotm6654

Well Known Member
I've got a problem that appears to be related to my global tables. In my DEV pathcode my Receiving App (P4312) works fine. In my CRPB733 pathcode, receiving does not update the Quant Open or the Cardex. I used the OW Cross Reference Facility to determine all of the objects used by this app and Object Transferred every last one of them (all object types) from DEV to CRP. I rebuilt a full package, deployed it, and it still DID NOT work in CRP.

Because it did not look like a code problem and we used the exact same data, I was baffled. I copied spec files over pair by pair (ie GBRSPEC.DDB & .XDB, FDASPEC.DDB & FDASPEC.XDB, etc.) and a pair at a time from the DEVB733 pathcode to the CRPB733 pathcode. I COPIED GLBLTBL.DDB & .XDB from DEV to CRP AND IT FINALLY WORKED.

WHAT I HAVE ALREADY TRIED:

1. Deleting GLOBAL TABLES: DID NOT WORK!
2. Deleting Data Dictionary: DID NOT WORK!
3. Object Xfered Table Objects & Data Structures: DID NOT WORK!
4. Contacted Support Line: Wha'dya expect?


MY QUESTION IS:

1. What's in those damn global tables spec files anyway? In your response you cannot use the term specs or tables, ie USE PLAIN WORDS. What do these do and why?
2. What in global tables would cause an app to work in one environment but not another given that I am just using one Data dictionary?
 
Ok, here's the scoop on glbltbl file as I understand it. I'll describe from start to finist how it's used...you can take what you need: p.s. had to use the word spec, but tried to explain :)

When the workstation is first installed with ow, the glbltbl.xdb and .ddb are empty. Once a user logs in and begins to access various applications, ow must access table specification information and data dictionary information for the data being accessed.

For example, when address book is opened, the F0101 table is read. This table accesses data items like Address Number (AN8), Search Type (AT1), Alpha Name (ALPH), etc.

One world reads the table specifications to get a list of columns (data dictionary) items, index information, etc. As a PERFORMANCE boost, when ow accesses the table for the first time and gets all the table information from the table spec files and all the corresponding column data from the data dictionary (JITI into dd spec files the first time, from the local dd spec file after that) and writes a "condensed" version of this info to the global table spec files. The next time the table is accessed, ow just has to read the glbltbl files (much smaller and quicker).

***************************

There are any number of scenarios where the glbltbl files can get out of sync with the rest of the system. Many of the following processes may very well synchronize the glbltbl files, but I can't promise which ones do:

1 - A user changes a data dictionary item. I'm almost 100% sure that this deletes any table info from the local glbltbl file related to the data item, so it is synced the next time the user accesses the related file, everything is great. However, that doesn't sync all the other workstations' glbltbl files. If you have dd replication turned on, it probably does. But otherwise, I'm thinking that only a workstation package that delivers empty glbltbl specs will do the job (full packages for sure, I'm not sure about update pkgs).

2 - A table is changed. Similar to above, you need to get this object's specifications deployed via a package AND the physical file regenerated in whatever fashion to reflect the changes (of course, all the normal warnings about losing data apply,...). In your note, you didn't list the objects you transferred from dev to crp. Did you transfer the tables involved?

3 - Careful with the cross reference tool. First, it only reports first level relationships. Second, often it doesn't report relationships internal to the business function calls (ie, tables, other functions). Third, it depends where you run it. If you want the relationships that exist in dev, you need to run the build there...just a side based on your description of your troubleshooting.

Was this part of a development project? Were any of the objects part of a recent development project? Have you, as the administrator, been asked to transfer anything in the same system code recently? My guess is that something did change and got transferred which affected this program. If you find anything...My advice is to go back to programmer and carefully review what they did for these changes:

1 - Changes to the P4312?
2 - What bsfn's did you change, if any?
3 - What tble's did you change, if any? What type of change? Index? TER? What kind of admin work required? Regen indices? Include in pkg (builds TER)? etc...
4 - Data Dictionary changes? What type of change? text? type? size? decimals? etc... Each of these can have very different impact on related tables.
5 - What bsvw's did you change? if any?

Finally, if none of this gives you any sparks, please repost. I'm sure I or someone else can come up with more.

Good Luck
 
Understanding Global Tables

I am experiencing the same issue that is described in the earlier post below, specifically a Batch Process does not work properly on a client. However, upon copying the GLBLTBL.DDB and .XDB from another client, this Batch Process now correctly work. Can someone shed more light on the following:

1. How Global Tables work, and what is stored in them.

2. How to "correct" Global Tables.

3. Is there an easy way to compare 2 Global Table files to identify any differences between them.
 
Re: Understanding Global Tables

parora,

If you rename/delete GLBLTBL.DDB and .XDB on a fat client, they will be rebuilt over a period of time as the the fat client is used, with their contents being "JITI'd" as required (as owguru mentioned in an earlier post in this thread). In addition the files can be rebuilt by running the R98CRTGL locally.

The attached Word document contains information on the contents of some TAM files and how to view them. The attachment to post 78813 also has some information on TAM files.

Additionally I have a request of all JDEList members. If replying to a thread, please do not change the subject as it tends to be misleading. If it is necessary to change the subject of the thread then it would probably be better to create another thread and, if needed, include a reference and may be a link to the thread or the particular post within the thread. Please see the attachment to post 90194 for information on creating a URL to link to a thread or post.
 

Attachments

  • 108537-TAM File Viewing.doc
    28 KB · Views: 241
Re: Understanding Global Tables

Hi,

To add some more info on the GLBTBL files. your GLBTBL files are built from your table spec TAM files (ddtabl, ddclmn, ddpkeyh and ddpkeyd). If the information for a table does not exist in these files then the GLBTBL spec cannot be built correctly for that table.

You can use UTB to browse the TAM files for the tables in question and see if you see any differences between the 2 environments.

Here is the extract from JDE doc - otm-02-0007.htm (Solution ID - 200783403).




Question 1 - When running R98CRTGL is the information for rebuilding the glbltbl TAM files taken from central objects or local specs ?

Answer: All R98CRTGL does is loop through F9860 and find all tables that are not bootstrap (F98611, F986101 etc) and central objects tables (F987*). It then calls the JDB API JDB_OpenTable for that table. At this point JDB is responsible for finding the table specs. JDB looks for specs in one of two places. First it will look in gbltbl.xdb and .ddb. Obviously, since the tables are being built by running R98CRTGL, it will not find them there. It then looks in local TAM (ddtabl, ddclmn, ddpkeyh and ddpkeyd) if it does not find table specs in local TAM it will give an error. JDB does not look at the central objects tables for table specs. Once JDB has located the table specs in TAM it will add them to gbltbl.xdb and .ddb. If the call to JDB_OpenTable is successful, R98CRTGL then calls JDB_CloseTable and proceeds to process the next table it finds in F9860.


--------------------------------------------------------------------------------

Question 2 - What is the Data Dictionary's role (R92TAM)

Answer: In order to build the table spec JDB needs to find the data dictionary specs for all the data items in the table. First it will look in local TAM (dddict). If it does not find the data item in dddict it will then go to look in the data dictionary tables in RDB and JITI the specs down to local TAM. The reason customers will run R92TAM before R98CRTGL is to save time on having to JITI data dictionary specs down. The TAM files created by R92TAM are put in the root of the client workstation.


--------------------------------------------------------------------------------

Question 3 - Where does R98CRTGL read the Table Definitions from when it rebuilds the glbltbl specs

Answer: DDCLMN specs will come from local TAM on the workstation where R98CRTGL is being run. Local Tam is the workstation specs or if you are on the deployment server then local Tam would be the path code specs.
 
Re: Understanding Global Tables

Hi,

Just an other addition.

ice_cube210 wrote:
[ QUOTE ]
You can use UTB to browse the TAM files...

[/ QUOTE ]

Making UTB able to explore local and server TAM/Spec files, you can add the following entry to your local jde.ini:

[INTERACTIVE RUNTIME]
TAMMenus=Show

Regards,

Zoltán
 
Back
Top