Unable to retrieve bussines views information - App p986162

Pearl Jabm

Pearl Jabm

Active Member
Ni. I've been these since a couple day ago. Some of my users are affected with this problem when they they send a UBE to server. They get the next error message:

Unable to get data Item table: f98616
Column name = 29
Dict name : PFA1

Unable to retrieve bussines views information - App p986162.

I did fix this error on my own computer by copying the global tables from a 'healthy' computer. But everytime I perform a package deployment to a client or a new license is isntalled the same error message is displayed when a report is send to server.

Any advice?
Thanks a lot.
 
Pearljabm

Welcome to The List.

From what you said, it sounds like some table specs have corrupted. It might be an idea to run UBE R9698711 from a "healthy" computer to check the actual tables against their specs. It may also prove interesting to compare the local specs for F98616 between an "unhealthy" computer an a "healthy" one and then compare those with what is actually in the database and the specs on the deployment server. They should all be in sync. If they aren't, and I'd guess that at least the "unhealthy" computers will be different, then you'll have to deploy the correct specs to the machines in error.

It's also a good idea to add your PeopleSoft setup information to your signature (go to My Home edit Personal information, scroll down to Signature (up to 255 characters)). You can see mine below. That way potential helpers will understand the context of your questions and be better able to help.

Anyway, all the best and I hope you are able to solve your problem. Let us know how it goes.
 
Hi Peter and thanks a lot for taking time to help me.

Today I put on practice what you said on the above post. I ran UBE R9698711 from a healthy computer and from a non-healthy one. The results were kind of horrible.

For Prototype the UBE runs great.

But for Production it failed from each computer I submitted.
Even from the DEPLOYMENT server (where the UBE was submited locally) and it shows this message:

'Unable to run report for environment
Cannot find Central Objects Data Source for this environment'

From what I was called before a 'healthy' computer the result of running the ube r9698711 was a error. Besides, even though I logged on PD the UBE was taking PY as the default environment to compare the specs. The error returned was:

No data Selected
ERROR: Unable to locate table in specified datasource for section: Table Details.

I hope this time you can give me a hand too.

Thanks a lot.
jabm Contreras
 
jabm Contreras,

You certainly got some "interesting" results. You mentioned in your original post that these problems started occuring "a couple of days ago." See if you can pin down the actual day the problems started. Then find out what changes were made around that time.

Did R9698711 you ran in Prototype (PY) report any inconsistancies?

When you ran the R9698711 in production, did you change the processing options to Production (PD)?

If you did then check your system set up. Check to make sure the Production Environment is set up correctly and that the data sources point to the correct locations. Also make sure that the OCM mappings are correct.

I wish you the best to resolve your problems. Please post your results.
 
Hi Peter,

After researching I found out the this problem started two days before I created a package. The package contained a Business Function, and it was defined for client and server. When the package was submitted for its compilation it ended up on error, both client and server. I didn't deploy the package to the clients computer nor the server (Enterprise). Two dayy after I created another package and when was deployed to clients their computers started to fail.

In another hand, I found inconsistancies when R9698711 was run on PY, and When it was run on DEPLOYMENT server, the PO were changed to point to PD yieldiong the next results:

Unable to run report for environment
Cannot find Central Objects Data Source for this environment.

We are sure that PD environment is right, we also checked our data sources (ODBC) and they are pointing to the right location, and for the OCM mappings we also tried to change some to make get them running locally with no results.

We think the the Enterprise server's specs went corrupted due to that package, and when a new package is deployed to client computer the specs go corrupted too, and the problem is getting bigger.

Another advice
Thanks a lot..
 
jabm Contreras,

It seems as though you are having major problems. Because the problem seems to be spreading when you deploy packages, I'd stop deploying packages until the problem is resolved.

You mentioned that the problems started when you had a package build fail. What objects were in the package? Does any object in the package reference F98616 or P986162 or associated business views? Where was the package built?

Another possibility: Do you package installs replace the JDE.INI? If so, there may be a problem with the new JDE.INI.

This problem is getting to the edge of my expertise. Someone else may be able to provide further help?

I hope you can get this problem solved quickly. Keep us posted please.
 
Peter, Belows is a list with the objects that were in the package. It was defined to client and server nad built on Deployment server logged on PD. As I told before, the submit package UBE (R09621 and R09622) ended up in error.

D58ICA010 DSTR
D58ICA9Z1 DSTR
F58ICA03 TBLE
F58ICA10 TBLE
F58ICA13 TBLE
F58ICA17 TBLE
F58ICA18 TBLE
N58ICA99 BSFN
P58ICA05 APPL
P58ICAGR APPL
V58ICA03 BSVW
V58ICA17 BSVW
V58ICA17A BSVW
V58ICA18 BSVW

All the objects were properly compiled except the N58ICA99 (Business Function) which causes the error. Later I created another opackage defined to client only and it cas built correctly.

Now, everytime I deploy a packaged on PD, the global tables files are updated and 'corrupted': posting to server is nos able since then.

The file fdaspec.xdb, fdaspec.ddb are updated too. I tried just copying these two files to my C:\B7\PD7333\specs folders after installing a small package but it didn't resolver the problem.

When installing a new package the JDE.ini is not updated, but I've noticed that everytime a package is installed the global tables from that compueter act as if they were deleted and re-created again.

Do you think this is due to corrupeted index?

Thanks a lot for your support.
 
jabm Contreras,

First of all, I'm going to be away this afternoon and tomorrow, but will be back on Friday (Australian Time). So my time is limited at the moment.

As you say the problem may be a corrupted index.

A few more points.

1) Can you do a complete install of a full package and, once installed, does it have the same problem with UBE's?

2) With a "healthy" computer, run R98CRTGL locally. This will create a full/complete copy of glbltbl.ddb and glbltbl.xdb in the spec directory of the pathcode for the environment you are using. On an "unhealthy" computer, in the same pathcode as the recreated glbltbl.ddb and glbltbl.xdb on the "healthy" computer, rename the glbltbl.ddb and glbltbl.xdb and then copy them from the "healthy" computer to the "unhealthy" computer. Then test the "unhealthy" computer (using an environment that uses the same pathcode) to see if the problem is fixed.

3) What errors did you get from the failed package build? What was the problem with N58ICA99 (Business Function)?

Once again, all the best for a solution.

If anyone else has two pennies to add, please do.
 
Hi Peter.

I got this fixed by adding news entries for some columns on Data Dictionary but I still trying to figure out whta may caused this problem.

I would to thank your effective help in this issue.

Thanks a lot!

jabm
 
Back
Top