Report issue after 5.0 upgrade 1

[brewerdude]

We just recently upgraded from 4.0 to 5.0. Everything went well, except for one slight issue. Out of all the reports, there are two that won't run properly.

Agent by Application Performance
Agent by Skillset Performance

When running either of these, you get the "There was an error while trying to print report. !Failed to access information from report file." This error occurs whether you run the canned report, or a modification of it. Also, the error occurs with both Revision 5 and Revision 6.3 of the fat client. Additionaly, it still occurs after loading PEP's NS040107G015C and NS040107SU12C. The server was built with PEP NN_SCCS_5.0_SU_03_S.

Any ideas?

 

[cgilmer]

Actually Yes I have had the same thing happen. All of the NON-Sysadmin Desktop logins got corrupted during your upgrade. I know this sounds unrelated and wierd but if you log in as sysadmin you will see the reports work. To fix it you out and rebuild the Users with a desktop login.

 

[cgilmer]

One thing I didn't try that you might be able to get to work would be to just un-click "Desktop" on the user configuration. Save it that way and then re-add it again with the same user ID.

Careful not to change the user id or it might mess up the "user-defined" reports since I believe they are stored on the local machine in an mdb file. They are associated by login ID. I rebuilt them with the same ID and they didn't lose anything.

 

[brewerdude]

Logged in as sysadmin and the reports worked. How crazy!!

I tried unclicking desktop on my login and got an error (of course). I'll try with someone else.

Did just get off the phone with Nextira, and they indicated that G016C, G017C, and G018C also need to be installed. But if it works with only SU12C and G015C and I'm logged in as sysadmin, not sure if those patches are actually going to fix the issue...

 

[cgilmer]

If it doesn't let you remove it due to scheduled reports remove everything but the desktop session and rebuild it. I had to go back and remove all of the agents from the supervisors and then delete the supervisor and agent sections of the user id. Then rebuild them and re-assocaite the agents to them.

Before you do this, or if you have to, make a note at the begining of the Title or Depeartment fields so that you can see which agents are associated with which supervisor. Then you can click on the column and sort the agents when you have to re-associate them.

 

[brewerdude]

I did try it with another user and it worked!

I never would of thought of such a thing. How did you figure this out?

 

[cgilmer]

Its defintely works without the patches... I only have 15,16 and 17 and it works here. I even removed them during the troubleshooting process to make sure it wasn't one of the patches causing the issue.

The problem I believe is in the database not the client. Its on the SCCS server which is why you have to make a physical change and save it in order for it to work again. Until I removed one of the configuration components it didn't change anything.

Another thing you can do to prove it is this... build a new ID and test it. I rebuilt my own since I'm just an administrator and didn't have any agents assigned to me to prove the concept worked.

 

[cgilmer]

When you call your vendor they insist on logging in with sysadmin. The reason is this ID is somehow exempt and can't be deleted or its properties changed so they always have access to everything. In this case it seems to have made it immune to whatever caused the corruption in the user table.

Once I saw it worked with sysadmin I deleted my ID and re-built it to test for corruption and sure enough it worked. I would have never assumed something like that would be the issue either. The only reason I even tried that was because it was the next logical thing to do in troubleshooting.

 

[brewerdude]

Excellent, thank you very much!! I did call the Nextira tech back and let her know the issue is related to the login and not the patches (the users I fixed are only on SU10).

It's kinda funny, because the PEP install solution came from one of their top TAC engineers.

 

[cgilmer]

The PEP install is the standard "don't troubleshoot this until the are on the latest patch". It probably wasn't the solution just the first step in their troubleshooting process. I know nothing bothers me more than to spend hours on something only to find out it was already addressed in a newer patch.

Strange thing is I called Nextira to let them know about it as well since I had opened a TAC ticket for safe measure. They should have already had this information available as the person I spoke to said she was going to add it into their known problem notes.

Worst thing was they told me that one customer had something even more strange happen. Supposidly after the upgrade they lost all their scripts/applications. So I guess we got off easy. About the only thing I noticed was that the applications weren't initially showing in the Real Time Displays so I bounced the Master Script and it forced and update.

After hearing that though I have made text copies of all my scripts and saved them in a folder on my local machine and the server.

 

[brewerdude]

I ended up installing all those patches on my system since I couldn't delete my desktop profile - and it worked. So, I guess that both procedures will fix the problem.

We had the same issue with the applications not appearing. Re-activating the master script did to the trick for us too.

We did do several "test runs" prior to going with a live install so our dba's could test their data extraction from Sybase. We ended up doing the install about five times in total. Our first live attempt failed because the restore kept failing. We ended up doing the backup directly from the old server to the new server, and didn't have an issue when we tried that.

 

[cgilmer]

Yep the other way was to delete the supervisor and agent part of the configuration but that required me to do alot of re-associating. Glad to hear they got a fix out for this now.

 

[dannab]

We recently upgraded our symposium to 5.0 and had the same problem.
We put in a ticket with Nortel and their tech called me back.
He said that there is a known problem with the user database conversion from 4.2 to 5.0 and permissions are lost for certain tables.
He also said that there is no pep to fix the problem (as of then) and that you should log in as administrator and delete the user and then readd.

We did this for all users who had report access and have not had the problem since.

dannab