Jump to content
The ibi Community has moved to a new platform: Please Sign In and choose Forgot Password to continue

Hey Guys, Getting issues in running Report with different us...


VisuaLizeFOCUS .

Recommended Posts

If you are crashing an agent, you can look the tscom temp folder for that agent number. It should have some bread crumbs giving you some clues.

Are you making hold files, in an app folder two users cannot write hold files to the same location at the same time. And visa-versa, you cant read a hold file, while someone else is still writing it.

I think if you study the code, youll find the reason.

Also, there are usually more details deeper than REPORTING SERVER ERROR. The console, if the agent is still idle, will have the last focerrnum. (focus error number). Or, the screen returned to the user, should have some more details than just the primary error message.

There is a reason, youll mainly need to dig a little deeper in to what is running and what resources is it using. It could be a simple as youre running out of disk space.

Start by looking at the edaprint.log in the reporting server console. Then ask for the full output screen of the error message, and see what else there is to see. And, review the code. There is a reason for any error.

Link to comment
Share on other sites

When / What are you doing when they see that error

Are they signing in to the Reporting Server console or the client, or are they running a report

When they see it - what screen are the looking at where they get that error (and what were they expecting to see)

Need a little more info.

Link to comment
Share on other sites

So guys the thing is I debugged this issue below are my findings:

 

 

When this issue comes: It comes when we run a report from HTML that passes the parameters to the procedure.

 

Access: Access to all the users are same but say if you run the report 10 times 7 times it will be a REPORTING SERVER ERROR and 3 times you will see the data.

 

After debug:

 

Since we migrated the data source from SQ and ORACLE to SNOWFLAKE and using ODBC driver not WF native one (as we are on 8202 and it doesnt have a native SNOWFLAKE DRIVE) . Formats of some columns causing the issue in DEFINE,COMPUTE and in IF conditions.

This is strange and came as a surprise for there is something in the code level due to Column formats that is causing this issue.

 

Let me know if you guys have any other thoughts .

Link to comment
Share on other sites

Are the column formats different in SNOWFLAKE than they were in Oracle or SQL Did you recreate the synonyms for the tables or are you using passthrough code

Weve seen where if the column formats dont match between two fields in a comparison (IF or WHERE statements) then it causes issues. And if your table column format is different than what the program was expecting because it changed in the source, that might cause an issue.

Link to comment
Share on other sites

I think, based on your description, its possible your issue might be data related.

Things like non-printable characters that might be inside your data could trip you up.

Are you getting crashed agents when you get the error

Can you cause the Reporting Server error reliably for debugging purposes

If you can force the error to happen, Id collect a savediag of that information and open a case with techsupport to ask the EDA guys to look into it.

Watch for data as your issue.

You can try throwing in

IF RECORDLIMIT EQ 1000

IF READLIMIT EQ 1000

And see if it always runs. Then go higher and higher until you find a point that it starts breaking.

There are lots of things you could try to do to locate bad data if that is in fact where your problem is.

If you can recreate the issue at will, just open a case and pass along your savediag to the EDA group.

Good luck!

Link to comment
Share on other sites

Hey Guys this issue is now resolved.

ISSUE : In the report we were using SQL Passthru and that SQL passthru is returning 5 columns which are concatenated dynamically to create a string BY ID. The length was exceeding so much due to SNOWFLAKE gives more size of data types as compared to SQL.

Two solutions:

 

We explicitly defined the size of those columns in SQL Query itself and it solved the issue.

From DB side we checked the size of those columns and made necessary changes on size and it solved the issue.

 

Thanks guys for your reply.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...