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

[VisuaLizeFOCUS .]

Hey Guys,

Getting issues in running Report with different users.

For some users it runs fine but for some users it gives REPORTING SERVER ERROR.

Can it be a Memory issue or some Query might be causing this issue

Any Ideas guys

Thanks.

[Martin Yergeau]

Could be several things,

Does their access the same

You should check logs

[VisuaLizeFOCUS .]

yes the access are same.

[john cullen]

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.

[Toby Mills]

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.

[VisuaLizeFOCUS .]

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 .

[Debra Waybright]

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.

[VisuaLizeFOCUS .]

Hi Debra,

Column formats in SQL and Oracle as compared to SNOWFLAKE are the same but the difference is of the size. That is causing some issue in reporting server while running the report.

[Toby Mills]

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!

[VisuaLizeFOCUS .]

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.