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

In 8203 we found that using SQL_Script as the format for hol...


Debra Waybright

Recommended Posts

In 8203 we found that using SQL_Script as the format for hold files created in InfoAssist helped things run faster. In 8207, this format seems to be causing problems. Im not entirely certain if using SQL_Script is what is causing it, so looking for help.

Heres what we are seeing. A hold file that has 3 joins and is saved as a temporary hold with SQL_Script is used in a report built new in 8207, but the report takes 15 minutes to open to edit. A report built new in 8207 has 4 temporary hold files all using SQL_Script format, cant build the report because when the hold files are joined I get a Null dataset error.

Thanks!

Link to comment
Share on other sites

it is difficult to answer your question without having details on what your are accessing or trying to do in your InfoAssist requests. Here are a few notes :

When you use ON TABLE HOLD AS TEST FORMAT SQL_SCRIPT (which is what InfoAssist creates) it (should) mean that you want to create a MASTER file TEST that points to a subselect meaning an SQL request that is created based on your IA/WebFOCUS Code. Normally HOLD FORMAT SQL_SCRIPT should always be very fast if you use it right because it does not manipulate any data it only creates an SQL request that you can reuse later as a subselect

However for this to work you have to be accessing an SQL database (MS SQL or ORACLE or whatever) and your request has to be fully optmized (meaning it can be totally translated to SQL)

Now if this is not the case (meaning your request is not accessing an SQL Data source or is doing heterogeneous JOINS and/or cannot be fully optimized): WebFOCUS uses a fall back option and HOLD FORMAT SQL_SCRIPT will create a binary HOLD file

Link to comment
Share on other sites

I understand it is just creating a subselect. We do hit a SQL database. Thats why it has always been so fast. It is odd to me that just importing these reports from 8203 to 8207 seems to break them. They are either really slow or give errors, even though it is hitting the exact same SQL database. I wonder if there is a setting we missed in 8207
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...