nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Information Object Locking Server

SteveRut

Hello,
 
So my boss asked me to create a rather large information object so our team can build custom reports as necessary. It has about 15 tables in it with optional joins. He wanted on info object so everyone would only have to go to one place. I published it to the server and it works fine for simple reports. But if I make a semi-complex report (using 3 tables with some dynamic parameters) the server locks up for about 30 minutes to an hour. I just want to know if I can change anything to make this work or if I should make the decision to break it up into many smaller info objects. 
 
Thanks
Steve

Find more posts tagged with

Comments

JFreeman

How much data are you bringing back?
What version of iHub are you using?
 
The best situation would be to not have one very large information object(IOB). However, you could dig into the execution time with increased logging on both the server and database side to try and isolate where the delay is occurring. From there it may be possible to improve the performance some.

SteveRut

Sometimes it is hundreds of rows of data and sometimes it is < 100. We are using iHub3. Is there a way to look at the SQL generated from the IOB? That way I can see if there is maybe an optional join that isn't getting dropped for some reason. I have a CASE statement in one of source columns. I am thinking maybe it isn't dropping that join when it isn't needed and making a mess of things.

JFreeman

The most accurate method is going to be to log the query on the database side. That was you will get the exact query that is hitting the database.
 
I believe you should also be able to get the query from the SMA file by editing it in the designer. However, based on your description, I believe logging the query on the database side is going to be the better option.

SteveRut

I split the tables with the CASE statements into their own IOBs and then joined them into the original IOB. It seems to have worked. I think the CASE was preventing the join from being optional. Thanks for your help

JFreeman

Thank you for the update.
I'm glad you got it working.
 
Let us know if you have additional questions.