100% found this document useful (1 vote)
7K views11 pages

Business Objects Universe Parameters

The document provides an alphabetical reference for SQL generation parameters in Universe Designer. These parameters control how SQL statements are generated from universes. Key parameters include: - ANSI92 - Specifies if SQL complies with ANSI92 standard - ARRAY_FETCH_SIZE_OPTIMIZATION - Controls optimization of array size for returned data - BEGIN_SQL - Allows prefixing SQL statements for accounting, prioritization, and workload management

Uploaded by

venkat143786
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
7K views11 pages

Business Objects Universe Parameters

The document provides an alphabetical reference for SQL generation parameters in Universe Designer. These parameters control how SQL statements are generated from universes. Key parameters include: - ANSI92 - Specifies if SQL complies with ANSI92 standard - ARRAY_FETCH_SIZE_OPTIMIZATION - Controls optimization of array size for returned data - BEGIN_SQL - Allows prefixing SQL statements for accounting, prioritization, and workload management

Uploaded by

venkat143786
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 11

Universe Designer

Universe SQL parameters reference


This section provides an alphabetical reference for the SQL generation parameters listed in the
Parameter page of the Universe Parameters dialog box in Designer. These are SQL parameters
that are common to most data access drivers. Each parameter is valid for the universe in which it
is set. Other RDBMS specific and connection parameters are listed in the data access parameter
(PRM) file for the target data access driver. Refer to the Data Access Guide for a reference to the
parameters in the PRM file.

ANSI92

ANSI92 = Yes|No
Values Yes/No
Default No
Specifies whether the SQL generated complies to the ANSI92 standard.
Yes: Enables the SQL generation compliant to ANSI92 standard.
Description
No: SQL generation behaves according to the PRM parameter
OUTER_JOIN_GENERATION.

ARRAY_FETCH_SIZE_OPTIMIZATION

ARRAY_FETCH_SIZE_OPTIMIZATION = Yes|No
Values Yes/No
Default Yes
An optimization algorithm can be used to optimize the size of the returned arrays
instead of using the default setting.
Description
Yes: All queries run on the Universe will benefit from the optimization.
No: Queries use the default value set.

AUTO_UPDATE_QUERY

AUTO_UPDATE_QUERY = Yes|No
Values Yes/No
Default No
Determines what happens when an object in a query is not available to a user profile.
Description Yes: Query is updated and the object is removed from the query.
No: Object is kept in the query.

BEGIN_SQL
BEGIN_SQL = <String>
Values String
Default Empty string
This is used to prefix SQL statements for accounting, prioritization, and workload
management. This parameter applies to any SQL generation, including document
generation and LOV queries.
It is supported in Web Intelligence, LiveOffice, and QaaWS. But it is ignored by
Desktop Intelligence and Crystal Reports.
Example for Teradata:
BEGIN_SQL=SET QUERY_BAND='string' for transaction;
This parameter requires a string that contains one or more name-value pairs,
Description separated by a semicolon, all inside single quotes. All SQL statements are prefixed
n with the parameter that follows BEGIN_SQL. The name-value pairs entered in this
parameter are written in the GetQueryBandPairs system table.
Example of three name-value pairs:
BEGIN_SQL=SET QUERY_BAND='UserID=Jones;JobID=980;AppID=TRM' for
transaction;
You can also use the @Variable function as the value in the name-value pair, the
returned value is enclosed in single quotes: BEGIN_SQL=SET
QUERY_BAND='USER='@Variable('BOUSER');Document='@Variable('DPNAM
E')';' for transaction;

BLOB_COMPARISON

BLOB_COMPARISON = Yes|No
Values Yes/No
Default No
Can be
No
edited?
Species if a query can be generated with a DISTINCT statement when a BLOB file
is used in the SELECT statement. It is related to the setting No Duplicate Row in
the query properties.
Description
Yes: The DISTINCT statement can be used within the query.
No: The DISTINCT statement cannot be used within the query even if the query
setting No Duplicate Row is on.

BOUNDARY_WEIGHT_TABLE

BOUNDARY_WEIGHT_TABLE = Integer 32bits [0-9]


Values Integer 32bits [0-9, or a negative integer]
Default -1
Description Allows you to optimize the FROM clause when tables have many rows.
If the table size (number of rows) is greater than the entered value, the table is
declared as a subquery:
FROM (SELECT col1, col2,......, coln, ,...., FROM Table_Name WHERE
simple condition).
A simple condition is defined as not having a subquery.
-1, 0, or any negative number means that this optimization is not used.
Optimization is not implemented when:
 The operator OR is in the query condition
 Only one table is involved in the SQL

Limitations  The query contains an outer join


 No condition is defined on the table that is being optimized

 The table being optimized is a derived table.


COLUMNS_SORT

COLUMNS_SORT = Yes|No
Values Yes/No
Default No
Determines the order that columns are displayed in tables in the Structure pane.
Description Yes: Columns are displayed in alphabetical order
No: Columns are displayed in the order they were retrieved from the database

COMBINE_WITHOUT_PARENTHESIS

COMBINE_WITHOUT_PARENTHESIS = Yes|No
Values Yes/No
Default No
Specifies whether or not to encapsulate a query with parentheses when it contains
UNION, INTERSECT or MINUS operators. Used with RedBrick.
Description
Yes Removes the parentheses.
No Leaves the parentheses.

COMBINED_WITH_SYNCHRO

COMBINED_WITH_SYNCHRO = Yes|No
Values Yes|No
Default No
Description Specifies whether to allow a query to execute that contains UNION,
INTERSECTION, or EXCEPT operators, and whose objects in each subquery are
incompatible.
Yes: Specifies that you do allow a query to execute that contains UNION,
INTERSECTION and EXCEPT operators, and whose objects in each subquery are
incompatible. This type of query generates synchronization (two blocks in the
report).
No: Specifies that you do not allow a query to execute that contains UNION,
INTERSECTION and EXCEPT operators, and whose objects in each subquery are
incompatible. When the query is executed the following error message is displayed:
"This query is too complex. One of the subqueries contains incompatible objects."
This is the default value.

COMPARE_CONTEXTS_WITH_JOINS

COMPARE_CONTEXTS_WITH_JOINS = Yes|No
Values Yes|No
Default Yes
Specifies how contexts are compared.
Yes: The system verifies that the contexts give the same joins.
Description
No: The system verifies that the contexts give the same sets of tables. This is the
default value.

CORE_ORDER_PRIORITY

CORE_ORDER_PRIORITY = Yes|No
Values Yes|No
Default No
This parameter applies to classes or objects that you add to a linked derived universe.
This parameter does not apply to the classes or objects in the core universe or in the
original derived universe. This parameter specifies in how you want the new classes
and objects to be organized in Designer.
See also the FIRST_LOCAL_CLASS_PRIORITY parameter.
Yes: Specifies that classes and objects are organized as follows:
 First core universe class

Core universe objects

Any derived universe objects belonging to first core universe class


Description
 Second core universe class

Core universe objects

Any derived universe objects belonging to second core universe class

 Other core universe classes...


 Derived universe classes and objects

No: Specifies that classes and objects follow the original order defined in the derived
universe. This is the default value.

CORRECT_AGGREGATED_CONDITIONS_IF_DRILL

CORRECT_AGGREGATED_CONDITIONS_IF_DRILL = Yes|No
Values Yes|No
Default No
Applies to Desktop Intelligence only. Specifies whether Desktop Intelligence can
aggregate measures in queries and conditions.
Yes: Desktop Intelligence can aggregate measures separately in the main query and
Description
the condition, if the query is drill enabled.
No: Desktop Intelligence cannot aggregate measures separately in the main query
and the condition, if the query is drill enabled.

CUMULATIVE_OBJECT_WHERE

CUMULATIVE_OBJECT_WHERE = Yes|No
Values Yes|No
Default No
This parameter applies to filtered objects only. Specifies how to combine the objects
WHERE clause with the query condition on those objects.
Yes: Specifies that WHERE clauses are combined with the main query condition
with the AND operator.
No : Specifies that the object's WHERE clause is combined with the condition for
this object.
Example:
If the condition is find all French clients different from John or American cities
different from New York, the SQL is:
Yes:
Description (customer.first_name <>
'John')
OR (city.city <> 'New York
AND customer_country.country = 'France'
AND city_country.country = 'USA'
No:
(customer.first_name <> 'John' AND
customer_country.country = 'France'
)
OR (city.city <> 'New York' AND
city_country.country = 'USA'
)
DECIMAL_COMMA

DECIMAL_COMMA = Yes|No
Values Yes|No
Default No
Specifies that Business Objects products insert a comma as a decimal separator when
necessary.
Yes: Business Objects products insert a comma as a decimal separator when
Description
necessary.
No: Business Objects products do not insert a comma as a decimal separator. This is
the default value.
DISTINCT_VALUES

DISTINCT_VALUES = GROUPBY|DISTINCT
Values GROUPBY|DISTINCT
Default DISTINCT
Specifies whether SQL is generated with a DISTINCT or GROUP BY clause in a list
of values and Query pane when the option "Do not retrieve duplicate rows" is active.
DISTINCT: The SQL is generated with a DISTINCT clause, for example;
Description
SELECT DISTINCT cust_name FROM Customers
GROUPBY: The SQL is generated with a GROUP BY clause, for example;
SELECT cust_name FROM Customers GROUP BY cust_name
END_SQL

END_SQL = String
Values String
Default <empty string>
Description The statement specified in this parameter is added at the end of each SQL statement.
For IBM DB2 databases, you can use the following:
END_SQL=FOR SELECT ONLY
The server will read blocks of data much faster.
Example Another example:
END_SQL=’write ‘ UNVID To Usage_Audit.Querieded_universe
Would write universe id to an audit table, this can be used to record other data such
as user and tables queried.
EVAL_WITHOUT_PARENTHESIS

EVAL_WITHOUT_PARENTHESIS = Yes|No
Values Yes|No
Default No
By default, the function @Select(Class\object) is replaced by the SELECT statement
for the object <Class\object> enclosed within brackets.
For example, when combining two @Select statements, @Select(objet1)
*@Select(objet2).
If the SQL(object1) = A-B and SQL(object2) =C,
then the operation is (A-B) * (C).
Description
You avoid the default adding of brackets by setting
EVAL_WITHOUT_PARENTHESIS = Yes. The operation is then A - B * C.
Yes: Brackets are removed from the SELECT statement for a function
@Select(Class\object)
No: Brackets are added around the Select statement for the function @Select(Class\
object).
FILTER_IN_FROM

FILTER_IN_FROM = Yes|No
Values Yes|No
Default No
Determines if query conditions are included in the FROM Clause. This setting is only
applicable if the other universe parameter setting ANSI92 is set to Yes.
Yes: When editing an outer join, the default behavior property selected in the drop
down list box of the Advanced Join properties dialog box in Designer, is set to "All
Description
objects in FROM".
No: When editing an outer join, the default behavior property selected in the drop
down list box of the Advanced Join properties dialog box in Designer is set to "No
object in FROM".

FIRST_LOCAL_CLASS_PRIORITY

FIRST_LOCAL_CLASS_PRIORITY = Yes|No
Values Yes|No
Default No
This parameter only applies to Desktop Intelligence.
Only taken into account when CORE_ORDER_PRIORITY=Yes.
Description Yes: Classes in the derived universe are listed first.
No: Objects and sub classes from the derived universe appear after those of the core
universe.
FORCE_SORTED_LOV

FORCE_SORTED_LOV = Yes|No
Values Yes|No
Default No
Retrieves a list of values that is sorted.
Description Yes: Specifies that the list of values is sorted.
No: Specifies that the list of values is not sorted.
INNERJOIN_IN_WHERE

INNERJOIN_IN_WHERE = Yes|No
Values Yes|No
Default You must manually enter the parameter to activate it.
Allows you to force the system to generate SQL syntax with all the inner joins in the
WHERE clause when ANSI92 is set to yes . This is only possible if a query contains
only inner joins (Does not contain FULL OUTER, RIGHT OUTER, or LEFT
OUTER joins).
Description Yes: If ANSI92 is set to yes, the system generates ANSI92 join syntax in the FROM
clause except when the query contains only inner joins. In this case, the inner joins
go into the WHERE clause.
No: If ANSI92 is set to Yes, the system generates ANSI 92 join syntax in the FROM
clause.
JOIN_BY_SQL

JOIN_BY_SQL = Yes|No
Values Yes|No
Default No
Specifies how multiple SQL statements are handled. Multiple statements can be
combined (provided that the database permits this).
Description Yes: Specifies that multiple SQL statements are combined.
No: Specifies that multiple SQL statements are not combined. This is the default
value.
MAX_INLIST_VALUES

MAX_INLIST_VALUES = [0-99]
Values Integer: min-1, max depends on DB
Default -1
Allows you to set the maximum number of values you may enter in a condition when
you use the IN LIST operator.
99: Specifies that you may enter up to 99 values when you create a condition using
Description the IN LIST operator.
The maximum authorized value you may enter depends on your database.
The value of -1 means that there is no restriction on the number of values returned,
except that imposed by the database.

OLAP_UNIVERSE

OLAP_UNIVERSE = Yes|No
Values Yes|No
Default No default value
Indicates if an OLAP universe is used. When Designer uses an OLAP universe, the
value is set to Yes and the parameter is visible in the SQL parameters list. When the
universe is not an OLAP universe, the parameter is not visible in the SQL parameters
Description
list.
Yes: The universe is an OLAP universe.
No: The universe is not an OLAP universe.

PATH_FINDER_OFF

Parameter is not listed by default. You must add the parameter manually to the list and set a
value.

PATH_FINDER_OFF= Yes|No
Values Yes|No
Default No default. You must manually enter the parameter.
Used for HPIW because the join generation is done by the database.
Description Yes: Joins are NOT generated in the query.
No: Joins are generated in the query. This is the default behavior.
REPLACE_COMMA_BY_CONCAT

REPLACE_COMMA_BY_CONCAT= Yes|No
Values Yes|No
Default No
In previous versions of Designer, a comma could be used to separate multiple fields
in an object Select statement. The comma was treated as a concatenation operator.
For universes that already use the comma in this way you can set
REPLACE_COMMA_BY_CONCAT to No to keep this behavior. In the current
Description version of Designer, this parameter is set to Yes by default, so that any expressions
using a comma in this way are automatically changed to use concatenation syntax.
Yes: Comma is replaced by the concatenation expression when multi field object is
found.
No: Keep the comma as it is.
SELFJOINS_IN_WHERE

SELFJOINS_IN_WHERE = Yes|No
Values Yes|No
Default No
Self-joins are usually included in the FROM clause. This allows you to force the
system to generate SQL syntax with all the conditions of a self-join in the WHERE
clause. the ANSI92 parameter must be set to Yes for this parameter to be taken into
account.
Description You must manually add the parameter to the list to activate it.
Yes: The conditions of a self-join go in the WHERE clause of the SQL query.
No: The syntax for self-joins is generated according to the ANSI 92 convention, and
conditions for a self-join go in the ON clause of the table join definition in the
FROM clause of the SQL query.

SHORTCUT_BEHAVIOR

SHORTCUT_BEHAVIOR = Global|Successive
Values Global|Successive
Default Successive
Description Specifies how shortcut joins are applied. This parameter was formerly listed as
GLOBAL_SHORTCUTS in the PRM files. The values have been changed to Global
for Yes, and Successive for No.
Global: Specifies that shortcut joins are considered one by one. A shortcut join is
applied only if it really bypasses one or more tables, and if it does not remove a table
from the join path used by a following shortcut join.
Successive: Specifies that all shortcut joins are applied. Note: If it generates a
Cartesian product, no shortcut joins are applied.

STORED_PROC_UNIVERSE

STORED_PROC_UNIVERSE = Yes|No
Values Yes|No
Default No
This value is automatically set to Yes when you create a universe that contains stored
procedures. Do not change this value manually.
Description
Yes: The universe you are creating/editing contains stored procedures.
No: The universe does not contain stored procedures.

THOROUGH_PARSE

THOROUGH_PARSE = Yes|No
Values Yes|No
Default No
Specifies the methodology used for default Parsing in the Query pane and individual
object parsing.
Yes: PREPARE, DESCRIBE, and EXECUTE statements are used to parse SQL for
Description
objects.
Prepare+DescribeCol+Execute
No: PREPARE and DESCRIBE statements are used to parse SQL for objects.
TRUST_CARDINALITIES

TRUST_CARDINALITIES = Yes|No
Values Yes|No
Default No
Allows you to optimize the SQL in case of inflated results.
Yes: For queries that include a measure, all conditions that inflate the measure and
Description do not appear in the Result Objects, are transformed to sub queries to ensure that
tables that may return false results for the measure are not included in the query.
No: No optimization is implemented.
UNICODE_STRINGS

UNICODE_STRINGS = Yes|No
Values Yes|No
Default No
Description Specifies whether the current universe can manipulate Unicode strings or not. Only
applies to Microsoft SQL Server and Oracle 9. If the database character set in the
SBO file is set as Unicode, then it is necessary to modify the SQL generation to
handle specific Unicode column types like NCHAR and NVARCHAR.
Yes: Conditions based on strings are formatted in the SQL according to the value for
a parameter UNICODE_PATTERN in the PRM file, for example for MS SQL
Server (sqlsrv.prm) : UNICODE_PATTERN=N$
The condition Customer_name='Arai ' becomes
Customer_name=N'Arai'.
Note: When you create a prompt with @Prompt syntax based on Unicode value, the
datatype should be 'U' not 'C'
No: All conditions based on strings are formatted in the standard SQL. For example
the condition Customer_name='Arai ' remains Customer_name='Arai'

Business Objects
http://www.businessobjects.com/
Support services
http://www.businessobjects.com/services/support/
Product Documentation on the Web
http://support.businessobjects.com/documentation/

You might also like