Query rule using query variables

Hi All,
I am working on a query rule in SharePoint 2013. I am trying to build a query text using query variables to provide profile based results to the users. The query text which I am using in the query builder is of the following format:
{SearchBoxQuery} CombinedLanguage:{User.PreferredContentLanguage}
but its not taking the user.preferredcontentlanguage value. Has any one worked on similar type of query rules using query variables? Please share your suggestions.
Thanks !!

Hi,
As I understand, you cannot get the user.preferredcontentlanguage value.
1. Make sure you have set the value of query variable {user.preferredcontentlanguage}, it will return -1 if not set.
2. Make sure you search in the right result source.
3. Please check the crawled property mapped to the managed property CombinedLanguage and make sure that there is at least one value indexed by the crawled property equal to the {user.preferredcontentlanguage}.
The article below is about the query variables.
https://technet.microsoft.com/en-us/library/jj683123.aspx
The article below is about the different query variables return different result examples.
http://techmikael.blogspot.in/2014/05/s15e03-query-variables-constant-trouble.html
Best regards
Sara Fan
TechNet Community Support

Similar Messages

Can we use session variables in BI publisher's Data Model SQL Query?

Hi Experts,
We need to implement Data level security in BI Publisher 11g.
In OBIEE we do so by using session variables, so just wanted to ask if we can use the same session variables in BI Publisher as well
ie can we include the where clause in the Data Models SQL Query like
Where ORG_ID = @{biServer.variables['NQ_SESSION.INV_ORG']}
Let me know your views on this.
PS: We are implementing EBS r12 security in BI Publisher.
Thanks

Read this -> OBIEE 11g: Error: "[nQSError: 23006] The session variable, NQ_SESSION.LAN_INT, has no value definition." when Creating a SQL Query using the session variable NQ_SESSION.LAN_INT in BI Publisher [ID 1511676.1]
Follow the ER - BUG:13607750 - NEED TO BE ABLE TO SET A SESSION VARIABLE IN OBIEE AND USE IT IN BI PUBLISHER
HTH,
SVS

Query don't use the right index when using bind variables

Hi people !
I need some help because I have an issue with a query that don t use the right Indexes as it should
First of all, I have mainly three tables :
ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
with quantity of packages prepared for each product (approximately 10 000 000 Records)
PRODUCT : Tables that contains the products (approximately 50 000 Records)
When I launch the query with hard coded values, it brings back response very fast
because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
(with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
Here is the correct explain plan when I execute the query with hard coded values :
SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = 'ADIDAS'
AND PRODUCT.CODE = 1234
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
4 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
4 TABLE ACCESS BY INDEX ROWID ORDER
777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
Now the problem is when the query is used in a Cursor with bind variables.
It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
to actually filter on a short period of time (only one day).
So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
Here is the bad explain plan :
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
722 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
2 TABLE ACCESS BY INDEX ROWID ORDER
1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
Now I have found two solutions to this problem :
1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
For example :
QUERY :=
'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = :CUSTOMER
AND PRODUCT.CODE = :CODE ';
These two solutions work but Number 1 is bad in theory because it uses a Hint
and Number 2 may be difficult to code.
So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
Thank you very much for support
Edited by: remaï on Apr 1, 2009 4:08 PM

What version of oracle you have? CBO work is different in 9i and 10g.
Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
(As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
Edited by: JustasVred on Apr 1, 2009 10:10 AM

WebI Prompts using BEx Query Variables

Hello,
I have the following issues with WebI report selection input paramaters (prompts) that use BW BEx Query variables. Could anyone please assist?
Issue 1:
The WebI report has one mandatory and two optional input paramaters (all paramaters from BW BEx Query). When I execute the report via WebI rich client directly, enter the value for mandatory input parameter and leave blanks for both optional input parameters, the report ran OK and has no issue. However, when I ran it through CMC a strange thing happen: I could not select the value for mandatory input paramater as it requires to have values for both optional input paramaters first (which I wish to have them blank and optional). When I refersh values for the mandatory paramater, it says "List of Values for current prompt requires values for following prompts:...(ie. the two optional parameters).
Anyone has any idea - it seems like it is a CMC issue for the WebI...
Issue 2:
Take the same WebI report above, the issue here is the order sequence of the prompts (ie. the selection input parameters). How can we change/control the sequence of the prompts? Whatever sequence of the varaiables (input paramters) in BW BEx Query, the WebI ignores it. Please advise.
Thanks & Regards,
Andy

I did not see separate thread for issue #1, therefore I'll us this thread.
I am running into similar issue when I get an error message ''List of Values for current prompt requires values for following prompts: <Name of the prompt>".
We are using BO V4, SP2, Patch 10 with SAP BW as DB via BEx queries.
I opened support ticket for this issue since obviousely it's still an issue after applying patch 10.
It's not an issue when 'Rich Internet Application' option is selected to view report in 'Reading' mode (via Launchpad Preferences then Web Inteligence; defautl value for viewing is 'Web').
I have not tried to use Client tools but even if it works with Client tools - it is not a solution for us. Our company does not plan to install client tools on end user computers.
Bigger issue us is that report scheduling invokes Web version (not Rich Internet Application). Therefore we cannot schedule report that is giving us problem described. I tried scheduling report from Launchpad and from CMC and both game me error highlighted.

BUG ? : ADF creating extra VO instance using bind variables in a LOV query

ADF 11.1.1.1.0
After "playing around" with bind variables Setting bind variables in view objects for LOV I've come across something strange that I've reproduce using the HR schema and tables Employees and Departments. Its a bit long but here goes :
Using the HR schema tables departments and employeesI'm trying to create a LOV (selectOneChoice) for the
employee department, the LOV having a bind variable that limits the values returned in this case returning only DepartmentId = 50
I've create a VO lovDepartment (not based on an EO) with the following query :
SELECT Departments.DEPARTMENT_ID,
       Departments.DEPARTMENT_NAME,
       Departments.MANAGER_ID,
       Departments.LOCATION_ID
FROM DEPARTMENTS Departments
where DEPARTMENT_ID = :pDeptIdA LOV has been defined on the DepartmentId attribute of the EmployeesView.
The lovDepartmentImpl overrides the executeQueryForCollection to set the bind variable value.
    @Override
    protected void executeQueryForCollection(Object object, Object[] object2,
                                             int i) {
        setNamedWhereClauseParam("pDeptId", "50");
        super.executeQueryForCollection(object, object2, i);
    }When using an ADF form to create a new employee the DepartmentId lov is empty.
Enabling SQL tracing shows the following :
[370] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.doSetWhereClause(-1, pDeptId, null)
[371] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.execute caused params to be "un"changed
[372] Column count: 4
[373] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0 ViewRowSetImpl.doSetWhereClause(-1, pDeptId, null)
[374] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1 ViewRowSetImpl.setNamedWhereClauseParam(pDeptId, 50)
[375] ViewObject: _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1 Created new QUERY statement
[376] _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1>#q computed SQLStmtBufLen: 235, actual=195, storing=225
[377] SELECT Departments.DEPARTMENT_ID,
       Departments.DEPARTMENT_NAME,
       Departments.MANAGER_ID,
       Departments.LOCATION_ID
FROM DEPARTMENTS Departments
where DEPARTMENT_ID = :pDeptId
[378] Bind params for ViewObject: _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1
[379] For RowSet : _LOCAL_VIEW_USAGE_model_EmployeesView_lovDepartment1_0
[380] Binding null of type 12 for "pDeptId"
[381] No Resource Bundle found but null value id:LOV_DepartmentId_LOVUIHints_NullValueId is defined in an ListBinding Definition.It would seem that 2 lovDepartment instances are used one at line 370 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1_0
and one at line 374 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1
The one at line 374 LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1 gets the variable bound at line 374
however LOCALVIEW_USAGE_model_EmployeesView_lovDepartment1_0 gets a null value and would explain the empty LOV
Can anybody explain what is happening here ? (and how to use bind variables in LOV queries)
Regards
Paul
(bump)
Edited by: Paul (MITsa) on Jul 14, 2009 10:46 AM
I've now tried all types of LOV from ChoiceList to Radio groupe by testing the application module - none of them work.....
Edited by: Paul (MITsa) on 14-Jul-2009 22:52

when you rinvoke executeQueryForCollection the bind variables are allready set and they exist in Object[] object2 method parameters.
in order to change them you need something like:
private void changeGenericBindVariable(Object[] params, String paramName, Object paramValue) {
for (int i = 0; i < params.length; i++) {
if (paramName.equals(((Object[])params)[0].toString()))
((Object[])params[i])[1] = paramValue;
* executeQueryForCollection - overridden for custom java data source support.
protected void executeQueryForCollection(Object qc, Object[] params,
int noUserParams) {
changeGenericBindVariable(params, "pDeptId", "50")
super.executeQueryForCollection(object, object2, i);
But its better to set bind variables before you executeQueryForCollection. like when you invoke LOV.
For cascading LOVs and the problems i have check:
[http://adfbugs.blogspot.com/2009/07/jdeveloper-11-r1-cascading-lov-bugs.html]

Using environment variables in a wmi query

Hello
I'm trying to use WMI Queries on Group Policy Preferences to targeting computers on my network.
I have a file named testfile.txt in Windows directory and I check its last modified date to replace the policy files if the date is older of than current file.
I set this query : Select * from CIM_DataFile where Name='C:\\Windows\\testfile.txt' and LastModified<'20140910145110.821214+180'.
The replace action occurs on all machines where windows directory is 'C:\Windows\'. But there are machines on network where windows is installed on directory 'C:\Windows7'.
So I was thinking to use %WindowsDir% environment variable in the WMI query to ckeck testfile.txt date on the correct directory where windows is installed.
I've tried different ways to use this environment variable in WMI query with no success (For example: Select * from CIM_DataFile where Name='%WindowsDir%\\testfile.txt' and LastModified<'20140910145110.821214+180').
Can someone help me with the correct syntax?
Thanks.

> I set this query : Select * from CIM_DataFile where
> Name='C:\\Windows\\testfile.txt' and
> LastModified<'20140910145110.821214+180'.
>
> The replace action occurs on all machines where windows directory is
> 'C:\Windows\'. But there are machines on network where windows is
> installed on directory 'C:\Windows7'.
>
> So I was thinking to use %WindowsDir% environment variable in the WMI
> query to ckeck testfile.txt date on the correct directory where windows
> is installed.
Short answer: You cannot use environment variables in WMI filters.
But you can modify your query:
Select * from CIM_DataFile where (Name = 'C:\\Windows\\testfile.txt' or
Name = 'C:\\Windows7\\testfile.txt' ) and
LastModified<'20140910145110.821214+180'
Event this one should work:
Select * from CIM_DataFile where Name like 'C:\\Windows%\\testfile.txt'
and LastModified<'20140910145110.821214+180'
BTW: The variable should be %windir% anyway, not %windowsdir% :)
Martin
Mal ein
GUTES Buch über GPOs lesen?
NO THEY ARE NOT EVIL, if you know what you are doing:
Good or bad GPOs?
And if IT bothers me - coke bottle design refreshment :))

Query taking too long when using bind variable

Hi All,
There is a query in our prod DB which runs very slow (approx 2 hours) when it uses Bind Variables (using JDBC thin client), and when i try passing the variable using TOAD/SQL developer it runs fine.
Explain Plan for running Query
SELECT STATEMENT ALL_ROWSCost: 146 Bytes: 379 Cardinality: 1
     21 SORT ORDER BY Cost: 146 Bytes: 379 Cardinality: 1
          20 NESTED LOOPS Cost: 145 Bytes: 379 Cardinality: 1
               17 HASH JOIN Cost: 22 Bytes: 42,558 Cardinality: 123
                    15 MERGE JOIN CARTESIAN Cost: 15 Bytes: 8,910 Cardinality: 27
                         12 FILTER
                              11 NESTED LOOPS OUTER Cost: 9 Bytes: 316 Cardinality: 1
                                   8 NESTED LOOPS OUTER Cost: 8 Bytes: 290 Cardinality: 1
                                        5 NESTED LOOPS Cost: 6 Bytes: 256 Cardinality: 1
                                             2 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 4 Bytes: 28 Cardinality: 1 Partition #: 9 Partition access computed by row location
                                                  1 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 3 Cardinality: 1
                                             4 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 228 Cardinality: 1
                                                  3 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1
                                        7 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 34 Cardinality: 1
                                             6 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1
                                   10 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 1 Bytes: 26 Cardinality: 1
                                        9 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 0 Cardinality: 1
                         14 BUFFER SORT Cost: 14 Bytes: 448 Cardinality: 32
                              13 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 6 Bytes: 448 Cardinality: 32
                    16 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144
               19 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1 Bytes: 33 Cardinality: 1
                    18 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 0 Cardinality: 1
Explain Plan for Slow Query
Plan
SELECT STATEMENT ALL_ROWSCost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728
     21 SORT ORDER BY Cost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728
          20 HASH JOIN Cost: 11,510,350 Bytes: 119,281,912 Cardinality: 314,728
               2 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1,741 Bytes: 177,540 Cardinality: 5,380
                    1 INDEX FULL SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 14 Cardinality: 5,380
               19 HASH JOIN Cost: 11,507,479 Bytes: 87,932,495,360 Cardinality: 254,140,160
                    3 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144
                    18 MERGE JOIN CARTESIAN Cost: 11,506,343 Bytes: 18,602,733,930 Cardinality: 56,371,921
                         15 FILTER
                              14 HASH JOIN RIGHT OUTER Cost: 3,930,405 Bytes: 556,672,868 Cardinality: 1,761,623
                                   5 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 6,763 Bytes: 892,580 Cardinality: 34,330
                                        4 INDEX FULL SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 63 Cardinality: 34,330
                                   13 HASH JOIN OUTER Cost: 3,923,634 Bytes: 510,870,670 Cardinality: 1,761,623
                                        10 HASH JOIN Cost: 2,096,894 Bytes: 450,975,488 Cardinality: 1,761,623
                                             7 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 2,763 Bytes: 52,083,248 Cardinality: 1,860,116 Partition #: 14 Partition access computed by row location
                                                  6 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 480 Cardinality: 334,821
                                             9 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,734,205 Bytes: 8,320,076,820 Cardinality: 36,491,565
                                                  8 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838
                                        12 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,733,836 Bytes: 1,331,145,696 Cardinality: 39,151,344
                                             11 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838
                         17 BUFFER SORT Cost: 11,499,580 Bytes: 448 Cardinality: 32
                              16 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 4 Bytes: 448 Cardinality: 32
How can I avoid that.
Thanks

Hello
Could you reformat your execution plans because they aren't particularly readable. The forums allow you to preserve the formatting of code or output by putting the symbol {noformat}{noformat} before and after the section of text you want to preserve formatting for.
If you write
{noformat}select * from v$version
{noformat}
it will be displayed asselect * from v$version
So can you run this above statement and post the output here so we know the full oracle version you are working with? And finally, it would be really helpful to see the query you are running. When you say it runs fine in Toad, is that when you replace the bind variables with the values or are you also using bind variables in Toad?
Cheers
David

Using Bind Variables in Parameter Form's Query

I want to use bind variables in the query of Parameter form. But
it does not allows. What is the other way out. The structure of
my Parameter form is as under:
State:
Customer:
Now I want that I want to list only those customer in the
Customer LOV which belongs to the selected state.
Thanks.
Muhammad Nadeem

Can we just link to an oracle form using a url still as we can with reports? I've built a report that requires the user to select from a dynamic list as well, and I know how to do this through forms, but can I simply call the form from a webpage?

Consequences of using unconstrained query variables?

I'm trying to determine what the consequences are (if any) of using
unconstrained query variables vs using variables with a contains clause in
order to navigate through collection fields.
In the Java Data Objects book the example given for collection field
navigation is as follows...
String filter = "customer.orders.contains(o) && o.dispatched == false";
q.declareVariables("Order o");
Using uncontrained variables this could be rewritten as...
String filter = "customer.orders.dispatched == false";
I'm using kodo 2.5.5 and need to navigate through multiple collection
fields. It is far simpler and easier for me to do this using the second
example above, but I can't find any documentation describing whether its a
good idea or not. So far the queries generated are correct.
Regards
Nathan

Hi Marc,
Using the query form with the variable is portable at present, but I can't
help wonder whether the spec will change in the future to make using QL
simpler. All of the examples given in both the JDO book and Kodo
documenation only ever demonstrate the simplest example. Trying to construct
a query that spans multiple collections is very time consuming as the
smallest error in the QL seems to result in "red herring" error messages.
I've constructed and example for you that uses both methods and produces
exactly the same SQL. I'm very tempted to continue using the unconstrained
method because it works and is so simple. Note that in the generated SQL,
the reason that the table "BOA" is joined to most of the other tables is due
to vertical inheritance. The example data model is a very cut down diagram
purely to show the relationships.
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Nathan-
You should use the query form with the variable, since it is portable
and spec compliant.
I'm actually a little surprised that the second filter works at all.
What is the SQL that results from both the queries?
In article <[email protected]>, nathan boyes wrote:
I'm trying to determine what the consequences are (if any) of using
unconstrained query variables vs using variables with a contains clause
in
order to navigate through collection fields.
In the Java Data Objects book the example given for collection field
navigation is as follows...
String filter = "customer.orders.contains(o) && o.dispatched == false";
q.declareVariables("Order o");
Using uncontrained variables this could be rewritten as...
String filter = "customer.orders.dispatched == false";
I'm using kodo 2.5.5 and need to navigate through multiple collection
fields. It is far simpler and easier for me to do this using the second
example above, but I can't find any documentation describing whether itsa
good idea or not. So far the queries generated are correct.
Regards
Nathan
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
begin 666 query syntax.txt
M"7!R:79A=&4@=F]I9"!P<F]J96-T475E<GE5;F-O;G-T<F%I;F5D*$ET96T@
M:71E;2E[#0H)"0T*"0E%>'1E;G0@97@@/2!C;VYT97AT+F=E=%!E<G-I<W0H
M*2YG971%>'1E;G0H4')O:F5C="YC;&%S<RP@=')U92D[#0H)"5%U97)Y('$[
M#0H)"4-O;&QE8W1I;VX@8V]L(#T@;G5L;#L-"@D)4W1R:6YG0G5F9F5R(&9I
M;'1E<B ](&YE=R!3=')I;F="=69F97(H*3L-"@T*"0EF:6QT97(N87!P96YD
M*")H;VUE1F]L9&5R+G)O;W1&;VQD97(N:6YD:7)E8W1#:&EL9')E;BYF;VQD
M97))=&5M<RYI=&5M(#T]('!A<DET96TB*3L-"@D)#0H)"7$@/2!C;VYT97AT
M+F=E=%!E<G-I<W0H*2YN97=1=65R>2AE>"D[#0H)"7$N9&5C;&%R94EM<&]R
M=',H(FEM<&]R="!A82YC;W)R97-P;VYD96YC92Y)=&5M.R(I.PT*"0EQ+F1E
M8VQA<F5087)A;65T97)S*"))=&5M('!A<DET96TB*3L-"@D)<2YS971&:6QT
M97(@*&9I;'1E<BYT;U-T<FEN9R@I*3L-"@D)#0H)"6-O;" ]("A#;VQL96-T
M:6]N*2!Q+F5X96-U=&4H:71E;2D[#0H)"0T*"7T-"@T*"7!R:79A=&4@=F]I
M9"!P<F]J96-T475E<GE5<VEN9U9A<FEA8FQE<RA)=&5M(&ET96TI>PT*"0D-
M"@D)17AT96YT(&5X(#T@8V]N=&5X="YG971097)S:7-T*"DN9V5T17AT96YT
M*%!R;VIE8W0N8VQA<W,L('1R=64I.PT*"0E1=65R>2!Q.PT*"0E#;VQL96-T
M:6]N(&-O;" ](&YU;&P[#0H-"@D)4W1R:6YG0G5F9F5R(&9I;'1E<B ](&YE
M=R!3=')I;F="=69F97(H*3L-"@D)4W1R:6YG0G5F9F5R(&EM<&]R=',@/2!N
M97<@4W1R:6YG0G5F9F5R*"D[#0H)"5-T<FEN9T)U9F9E<B!V87)I86)L97,@
M/2!N97<@4W1R:6YG0G5F9F5R*"D[#0H)"0T*"0EI;7!O<G1S+F%P<&5N9"@B
M:6UP;W)T(&%A+F-O<G)E<W!O;F1E;F-E+DET96T[("(I.PT*"0EI;7!O<G1S
M+F%P<&5N9"@B:6UP;W)T(&%A+F9O;&1E<BY&;VQD97))=&5M.R B*3L-"@D)
M:6UP;W)T<RYA<'!E;F0H(FEM<&]R="!A82YF;VQD97(N1F]L9&5R.R(I.PT*
M#0H)"79A<FEA8FQE<RYA<'!E;F0H(D9O;&1E<B!V87));F1I<F5C=$-H:6QD
M1F]L9&5R.R(I.PT*"0EV87)I86)L97,N87!P96YD*")&;VQD97))=&5M('9A
M<D9O;&1E<DET96TB*3L-"@D)"0D-"@D)9FEL=&5R+F%P<&5N9"@B:&]M949O
M;&1E<BYR;V]T1F]L9&5R+FEN9&ER96-T0VAI;&1R96XN8V]N=&%I;G,H=F%R
M26YD:7)E8W1#:&EL9$9O;&1E<BD@)B8@(BD[#0H)"69I;'1E<BYA<'!E;F0H
M(G9A<DEN9&ER96-T0VAI;&1&;VQD97(N9F]L9&5R271E;7,N8V]N=&%I;G,H
M=F%R1F]L9&5R271E;2D@)B8@(BD[#0H)"69I;'1E<BYA<'!E;F0H(G9A<D9O
M;&1E<DET96TN:71E;2 ]/2!P87))=&5M(BD[#0H)"0T*"0EQ(#T@8V]N=&5X
M="YG971097)S:7-T*"DN;F5W475E<[email protected]*"0EQ+F1E8VQA<F5);7!O
M<G1S*&EM<&]R=',N=&]3=')I;F<H*2D[#0H)"7$N9&5C;&%R95!A<F%M971E
M<G,H(DET96T@<&%R271E;2(I.PT*"0EQ+F1E8VQA<F5687)I86)L97,H=F%R
M:6%B;&5S+G1O4W1R:6YG*"DI.PT*"0EQ+G-E=$9I;'1E<B H9FEL=&5R+G1O
M4W1R:6YG*"DI.PT*"0D-"@D)8V]L(#T@*$-O;&QE8W1I;VXI('$N97AE8W5T
692AI=&5M*3L-"@D)#0H)"0T*"7T-"@``
`
end
begin 666 generatedQuery.sql
M4T5,14-4($1)4U1)3D-4( T*"70P+DE$+" -"@ET,2Y*1$]#3$%34U@L( T*
M"70Q+DI$3TQ/0TM8+" -"@ET,2Y#55)214Y404Q415)!5$E/3DE$+" -"@ET
M,"Y!0U1)5D5?1"P@#0H)=# N8V]M<&]N96YT260L( T*"70P+F1A=&52;VQE
M365M8F5R<TUO9&EF:65D7V0L( T*"70P+DAO;65&;VQD97))1"P@#0H)=# N
M3U))1TE.04Q04D]*14-4240L( T*"70P+G!R;VIE8W13=&%T=7,L( T*"70P
M+E)%1D5214Y#15]$+" -"@ET,"Y32$]25$1%4T-27T0@#0I&4D]-( T*"5!2
M3TI%0U0@=# @24Y.15(@2D])3B -"@E"3T$@=#$@3TX@=# N240@/2!T,2Y)
M1"!)3DY%4B!*3TE.( T*"4A/345&3TQ$15(@=#(@3TX@=# N2&]M949O;&1E
M<DE$(#T@=#([email protected](@2D])3B -"@E"3T$@=#,@3TX@=#(N240@/2!T
M,RY)1"!)3DY%4B!*3TE.( T*"49/3$1%4B!T-"!/3B!T,BYR;V]T1F]L9&5R
M240@/2!T-"Y)1"!)3DY%4B!*3TE.( T*"4)/02!T-2!/3B!T-"Y)1" ]('0U
M+DE$($E.3D52($I/24X@#0H)26YD:7)E8W1#:&EL9$9O;&1E<B!T-B!/3B!T
M-"Y)1" ]('0V+FEN9&ER96-T4&%[email protected](@2D])3B -"@E&3TQ$
M15(@=#<@3TX@=#8N:6YD:7)E8W1#:&EL9$ED(#T@=#<[email protected](@2D])
M3B -"@E"3T$@=#@@3TX@=#<N240@/2!T."Y)1"!)3DY%4B!*3TE.( T*"49/
M3$1%4DE414T@=#D@3TX@=#<N240@/2!T.2YP87)E;G1F;VQD97)I9"!)3DY%
M4B!*3TE.( T*"4)/02!T,3 @3TX@=#DN240@/2!T,3 N240@#0I72$5212 -
M"@DH=#DN:71E;6ED(#T@/RD@04Y$( T*"70Q+DI$3T-,05-36" ](#\I.B!;
M<F5U<V5D/3$[<&%R86US/7LH:6YT*3,Q,3$L*%-T<FEN9REC;VTN;6%L;&5S
C;VYS+G-E<G9I8V5N970N86$N<')O:F5C="Y0<F]J96-T?5T`
`
end
begin 666 example datamodel.doc
MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````!
M````(@``````````$ ``) ````$```#^____`````"$```#_____________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M____________________________________________________________
M_______________________LI<$`"R )! ``\!*_````````$ ``````! ``
M?@0```X`8FIB:N `X `````````````````````````)!!8`+@P``()J`0""
M:@$`% ``````````````````````````````:0````````#__P\`````````
M``#__P\```````````#__P\``````````````````````&P``````*@`````
M````J ```*@`````````J `````````8`@```````!@"````````& (``!0`
M`````````````$P"````````? (```````!\`@```````'P"````````? (`
M``P```"(`@``# ```$P"````````X@X``+8```"@`@```````* "````````
MH (```````"@`@```````* "````````A0L```````"%"P```````(4+````
M````80X```(```!C#@```````&,.````````8PX```````!C#@```````&,.
M````````8PX``"0```"8#P``( (``+@1``!&````APX``!4`````````````
M````````````& (```````"%"P````````````````````````````!'"0``
M/@(``(4+````````A0L```````"%"P```````(<.````````40P```````"H
M`````````*@`````````H (``````````````````* "``"G!@``G X``!8`
M``!1# ```````%$,````````40P```````"%"P``0 ```*@````(`0``H (`
M```````8`@```````* "````````80X``````````````````%$,````````
M````````````````````````````````````````````````````````````
M````A0L```````!A#@```````%$,```0`@``40P``````````````````&$.
M````````L $``&@````8`@``````````````````````````````````````
M````````````````````````````````````````````80X```````"@`@``
M`````)0"```,````,*'_R.K3PP%,`@``, ```'P"````````Q0L``#H```!A
M#@``````````````````80X```````"R#@``, ```.(.````````80X`````
M``#^$0```````/\+``!2````_A$```````!A#@```````%$,````````+ (`
M`!(````^`@``#@```*@`````````J ````````"H`````````*@`````````
M`@#9````" @(" @(" @(" @(" @(" @(" UP<F]J96-T#0UH;VUE1F]L9&5R
M#0U2;V]T1F]L9&5R("A&;VQD97(@;V)J96-T*0T-26YD:7)E8W1#:&EL9')E
M;B H1F]L9&5R(&]B:F5C="D-#69O;&1E<DET96T-#6ET96T-#0T-#0T-````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````! ``$P0``'X$``#Q````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````!P#:@````!#2A0`50@!;4@`!&Y(``1S2 D$=0@!`@`$```4
M! ``' 0``!T$```H! ``*00``$0$``!%! ``9@0``&<$``!R! ``<P0``'@$
M``!Y! ``>@0``'L$``!\! ``?00``'X$``#]````````````````_0``````
M`````````/T```````````````#]````````````````_0``````````````
M`/T```````````````#]````````````````_0```````````````/T`````
M``````````#]````````````````_0```````````````/T`````````````
M``#]````````````````_0```````````````/T```````````````#]````
M````````````_0```````````````/T`````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````$````2``0``!0$``!]! ``_?T`````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````$! `!`0(L`#&0: $?L((N(+#&02&P
M" <BL @'(Y"@!220H 4EL ``%[#$`ABPQ (,D,0"````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````% `/``H``0!I``\``P```````````#@``$#Q
M_P(`. `,``8`3@!O`'(`;0!A`&P````"````& !#2A@`7T@!!&%*& !M2 D,
M<T@)#'1("00````````````````````````\`$% \O^A`#P`# `6`$0`90!F
M`&$`=0!L`'0`( !0`&$`<@!A`&<`<@!A`' `: `@`$8`;P!N`'0`````````
M``````````````D````5````,0```%,```!?````90```&8```!G````: ``
M`'X````!````````````_____P($`````````0```````````/____\#! ``
M``````$```````````#_____! 0````````!````````````_____P4$````
M`````0```````````/____\&! ````````$```````````#_____!P0`````
M```(`````0````$`_____P``````````!@````(````!`/____\`````````
M`/____\``````0#_____```````````'`````P``````````````````````
M``````D````5````,0```%,```!?````90```&8```!G````: ```&L`````
M```````!```````"```````#```````$```````%```````&``````@'````
M``@(``````C__P``````````?@````0```P```4`_____P$````&(/__`0`B
M)J,```````````!^`````````````````!0```!_````G@``````````````
M`( ```" F@```````````````( ```" ``0``'X$```#``````0``'X$```$
M``````0``'T$```%````#P``\#@```````;P& ```"($```"````& ````$`
M```!````(@```$ `'O$0````__\`````_P" @( `]P``$ `/``+P7@8``! `
M"/ (````% ```"$$```/``/P_ 4```\`!/ H`````0`)\! `````````````
M`````````````@`*\ @`````! ``!0````\`!/!"````$@`*\ @````"! ``
M``H``!,`"_ &````@ ````$````0\ 0````/```````1\ 0````$```````-
M\ 0```````$`#P`$\$(````2``KP" ````,$````"@``$P`+\ 8```" ````
M`@```!#P! ```! ``````!'P! ````4```````WP! ```````@`/``3P0@``
M`!(`"O (````! 0````*```3``OP!@```( ````#````$/ $`````0``````
M$? $````#0``````#? $```````#``\`!/!"````$@`*\ @````%! ````H`
M`!,`"_ &````@ ````0````0\ 0````````````1\ 0````-```````-\ 0`
M``````0`#P`$\$(````2``KP" ````8$````"@``$P`+\ 8```" ````!0``
M`!#P! ```!$``````!'P! ````H```````WP! ``````!0`/``3P0@```!(`
M"O (````!P0````*```3``OP!@```( ````&````$/ $````$@``````$? $
M````"P``````#? $```````&``\`!/!(````0@$*\ @````)! ````H``$,`
M"_ 8````1 $$````?P$```$`OP$``! `_P$0`! ````0\ 0````.```````1
M\ 0````#````#P`$\$@```!"`0KP" ````H$````"@``0P`+\!@```!$`00`
M``!_`0```0"_`0``$ #_`1 `$ ```!#P! ````T``````!'P! ````,````/
M``3P2 ```$(!"O (````"P0````*``!#``OP& ```$0!! ```'\!```!`+\!
M```0`/\!$ `0````$/ $````# ``````$? $`````P````\`!/!(````0@$*
M\ @````,! ````H``$,`"_ 8````1 $$````?P$```$`OP$``! `_P$0`! `
M```0\ 0````+```````1\ 0````#````#P`$\$@```!"`0KP" ````T$````
M"@``0P`+\!@```!$`00```!_`0```0"_`0``$ #_`1 `$ ```!#P! ````H`
M`````!'P! ````,````/``3P2 ```$(!"O (````& 0``$ *``!#``OP& ``
M`$0!! ```'\!```!`+\!```0`/\!$ `0````$/ $````" ``````$? $````
M!0````\`!/!(````0@$*\ @````9! ````H``$,`"_ 8````1 $$````?P$`
M``$`OP$``! `_P$0`! ````0\ 0````)```````1\ 0````&````#P`$\$@`
M``!"`0KP" ```!L$``! "@``0P`+\!@```!$`00```!_`0```0"_`0``$ #_
M`1 `$ ```!#P! ````<``````!'P! ````4````/``3P2 ```$(!"O (````
M' 0````*``!#``OP& ```$0!! ```'\!```!`+\!```0`/\!$ `0````$/ $
M````!@``````$? $````!0````\`!/!(````0@$*\ @````=! ````H``$,`
M"_ 8````1 $$````?P$```$`OP$``! `_P$0`! ````0\ 0````%```````1
M\ 0````%````#P`$\$@```!"`0KP" ```!X$``! "@``0P`+\!@```!$`00`
M``!_`0```0"_`0``$ #_`1 `$ ```!#P! ````0``````!'P! ````4````/
M``3P2 ```$(!"O (````'P0````*``!#``OP& ```$0!! ```'\!```!`+\!
M```0`/\!$ `0````$/ $`````P``````$? $````!0````\`!/!(````0@$*
M\ @````@! ``0 H``$,`"_ 8````1 $$````?P$```$`OP$``! `_P$0`! `
M```0\ 0````"```````1\ 0````%````#P`$\$(````2``KP" ````$$````
M#@``4P`+\!X```"_`0``$ #+`0````#_`0``" `$`PD````_`P$``0```!'P
M! ````$``````````0````(````#````! ````4````&````!P````@````)
M````"@````L````,````#0````X````/````$ ```!$````2````?@````4$
M```(!P``S!4``&04``#H%P``= ``````! 0```@'```L$ ``_!(``$@2``!T
M```````@! ``) D``&P;``#8"0``(!P``'0``````!\$``#8"0``;!L``(P*
M```@' ``= ``````'@0``"0)```8%0``V D``,P5``!T```````=! ``V D`
M`!@5``","@``S!4``'0``````!P$```D"0``/!X``-@)``#P'@``= ``````
M&P0``-@)```\'@``C H``/ >``!T```````8! ``V D``$@2``","@``_!(`
M`'0``````!D$```D"0``2!(``-@)``#\$@``= ``````#00``-@)```\'@``
MV D``'0B``!T```````,! ``V D``.@7``#8"0``(!P``'0```````L$``#8
M"0``2!(``-@)``#,%0``= ``````"@0``-@)``"H# ``V D``"P0``!T````
M```)! ``V D``%0&``#8"0``C H``'0```````($```(!P``. 0``%P-``!4
M!@``= ```````P0```@'``","@``7 T``*@,``!T```````&! ``" <``" <
M``!<#0``/!X``'0```````<$```(!P``="(``%P-``"0) ``= ``````````
M`!0````=````)P```"D````S````10```%4```!G````<0```'\````'``<`
M' `'`!P`!P`<``<`' `'```````4````&P```!T````G````9P```'$```!S
M````=P```'\````'`#H`!P`Z``<`.@`'`#H`!P````````````$````!````
M`@````H````1````$0```!,````4````&P```!T```!\````?P````0``P`$
M``,`! `#``0``P`'``0``P`$``,`__\&````!P!N`&$`8@!O`'D`90!S`&P`
M0P`Z`%P`1 !O`&,`=0!M`&4`;@!T`',`( !A`&X`9 `@`%,`90!T`'0`:0!N
M`&<`<P!<`&X`80!B`&\`>0!E`',`7 !!`' `< !L`&D`8P!A`'0`:0!O`&X`
M( !$`&$`= !A`%P`30!I`&,`<@!O`',`;P!F`'0`7 !7`&\`<@!D`%P`00!U
M`'0`;P!2`&4`8P!O`'8`90!R`'D`( !S`&$`=@!E`" `;P!F`" `90!X`&$`
M;0!P`&P`90`@`&0`80!T`&$`;0!O`&0`90!L`"X`80!S`&0`!P!N`&$`8@!O
M`'D`90!S`#\`0P`Z`%P`1 !O`&,`=0!M`&4`;@!T`',`( !A`&X`9 `@`%,`
M90!T`'0`:0!N`&<`<P!<`&X`80!B`&\`>0!E`',`7 !$`&4`<P!K`'0`;P!P
M`%P`90!X`&$`;0!P`&P`90`@`&0`80!T`&$`;0!O`&0`90!L`"X`9 !O`&,`
M!P!N`&$`8@!O`'D`90!S`#\`0P`Z`%P`1 !O`&,`=0!M`&4`;@!T`',`( !A
M`&X`9 `@`%,`90!T`'0`:0!N`&<`<P!<`&X`80!B`&\`>0!E`',`7 !$`&4`
M<P!K`'0`;P!P`%P`90!X`&$`;0!P`&P`90`@`&0`80!T`&$`;0!O`&0`90!L
M`"X`9 !O`&,`_T #@ $````````````0`/(#`0`!````````````````````
M```"$ ````````!^````0 ``" ! ``#__P$````'`%4`;@!K`&X`;P!W`&X`
M__\!``@``````````````/__`0``````__\```(`__\`````__\```(`__\`
M`````P```$<6D $```("!@,%! 4"`P2'>@`@````@ @`````````_P$`````
M``!4`&D`;0!E`',`( !.`&4`=P`@`%(`;P!M`&$`;@```#46D $"``4%`0(!
M!P8"!0<`````````$ ``````````````@ ````!3`'D`;0!B`&\`; ```#,F
MD $```(+!@0"`@("`@2'>@`@````@ @`````````_P$```````!!`'(`:0!A
M`&P````B``0`<0B(& #PT (``&@!`````-,R@4;3,H%&``````,`!P``````
M`````````0`!````! `#$ $```````````````$``0````$`````````(0,`
M\! `````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M" >@!;0`M "!@3(P````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````(```!3`P``````,H,1`/ 0``@`````````````````````````````
M````````````__\2````````````````````!P!N`&$`8@!O`'D`90!S``<`
M;@!A`&(`;P!Y`&4`<P``````````````````````````````_O\```4!`@``
M`````````````````````0```."%G_+Y3V@0JY$(`"LGL]DP````5 $``! `
M```!````B ````(```"0`````P```)P````$````J ````4```"X````!P``
M`,0````(````V ````D```#H````$@```/0````*````$ $```P````<`0``
M#0```"@!```.````- $```\````\`0``$ ```$0!```3````3 $```(```#D
M! ``'@````$``````',`'@````$``````',`'@````@```!N86)O>65S`!X`
M```!`````&%B;QX````+````3F]R;6%L+F1O= ``'@````@```!N86)O>65S
M`!X````"````,P!B;QX````3````36EC<F]S;V9T(%=O<[email protected]``! ````
M`.I6^@````! `````/* KNK3PP% `````/* KNK3PP$#`````0````,`````
M`````P`````````#````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````````````````````````````````/[_```%`0(`
M``````````````````````$````"U<W5G"X;$).7" `K+/FN, `````!```,
M`````0```&@````/````< ````4```"4````!@```)P````1````I ```!<`
M``"L````"P```+0````0````O ```!,```#$````%@```,P````-````U ``
M``P```#A`````@```.0$```>````&@```$UA;&QE<V]N<R!3=&5P:&5N($IA
M8W%U97,`( `#`````0````,````!`````P`````````#````#AL)``L`````
M````"P`````````+``````````L`````````'A ```$````!``````P0```"
M````'@````8```!4:71L90`#`````0``````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````````````````````````!`````@``
M``,````$````!0````8````'````_O___PD````*````"P````P````-````
M#@````\````0````_O___Q(````3````% ```!4````6````%P```!@```#^
M____&@```!L````<````'0```!X````?````( ```/[____]____(P```/[_
M___^_____O____________

ORA-01006 Using Bind Variables In A Dynamic SQL Contains Query

I have the following dynamic SQL query :-
declare
TYPE typ_sql IS REF CURSOR;
ltyp_sql typ_sql;
lv_sql VARCHAR2(100);
begin
lv_sql := 'SELECT arx_id FROM arx WHERE CONTAINS ';
lv_sql := lv_sql || (arx_full,''(:b1) WITHIN ui'') > 0';
open ltyp_sql FOR v_sql USING ln_id;
fetch ......
close ......
end;
When the code tries to open the cursor it gives the above error. I presume it is the way Oracle is expanding the bind variable but I cannot find anything in the docs to say why this is happening or whether you can do this or not using bind variables ( CONTAINS query ). Any help would be appreciated, thanks,
Stuart.

lv_sql || '(arx_full, :b1 || '' within ui'') > 0';

Query BI7: problem in using the variables of referenced caracteristics.

Dear Experts,
I have posted a question in "BI General" yesterday. Untill now, I haven't got any reply. So i decide to post it under this subject. And I hope somebody can help me.
A query was created on the basis of an Infoset, in which there are many caracteristics created with reference to some existed caracteristics.
However, in the new query, I was not able to use those variables which are already created and attached to the existed caracteristics. What's more, some variables are declared in the SAP exit, and they are compulsory in the new query.
Given a very short delay in the project, it seems to me impossible to create all the variables for my new query.
Is there anybody who has a solution or an idea for this problem?
Thanks in advance!!!

I was not able to use those variables which are already created and attached to the existed caracteristics.
Ya,you cannot use the same variable to two(or more) infoobjects (though they use same reference) but what I observed in was eventhoug you get Error messaga when you do check in query designer.If you ignore and just execute the query it simply works.Just give it a try.
Else you need to create new variables similar to existing one and use it.

How do I...Mimic Replacement Path with Query using Customer Variable Exits?

Hello SDN:
We are on BW 3.5 SP16.
We are currently using a replacement path Query(RP) with variables
to populate a variable in another Query(T).
The problem we are having is with performance.
The entry of variables in replacement path Query(RP) is optional (This is necessary there cannot be required values)
When results from Replacement Path Query are small performance is fine. (e.g. 10 seconds)
When results from Replacement path query are large performance suffers. (e.g. 1+ minutes)
Users are free to leave the replacement path variables empty resulting in a large set of data to be replaced. This is the worst performance case.
We would like to discover a way to conditionally execute the replacement path query. That is if users do not enter values for the replacement Query(RP) variables do not execute the replacement path query(RP).
Does anyone know if this is possible within reason and in customer exit space?
We have reviewed the situation from all angles and the requirement for the replacement path FUNCTIONALITY and the freedom for the user to leave variable values blank remains.
I've been searching and reading SDN and SAP notes for about a week and do not find threads which address this situation.
We are also exploring Customer variable exits to mimic replacement path functionality
(different topic subject="How do I...Mimic Replacement Path with Query using Customer Variable Exits?")
Any help will be appreciated
Many thanks
David Schuh

My appologies-I posted this message with the wrong subject. I will repost it with appropriate subject.
dave schuh

Simple use of variables in query

Hi,
i've just started using PL/SQL and as a long time user of TSQL the syntax is a bit confusing for me. I'm trying to test a simple query - using a variable to select some rows from a table. Lest assume that we have a table with data from different days and we want to view data from specific day.
I could use:
SELECT * FROM TABLE
where TRADE_DATE = '2010-10-23'
but what i would like to do is to pass the date value as a variable, in TSQL i'd just write:
declare @trade_date datetime
set @trade_date = '2010-10-23'
SELECT * FROM TABLE
where TRADE_DATE = @trade_date
Could someone help me and write the last query using PL/SQL syntax?
Also - it there some kind of a tutorial for people like me? comparison of simple queries written in both languages? tried to google it but didn't have luck.

There are a couple of differences besides variable syntax. The variable would look like this in PL/SQL:
declare
    v_trade_date date := DATE '2010-10-23';
begin
    select * into ????? -- see below
    from   table
    where trade_date = v_trade_date;
end;However the next difference is that PL/SQL does not implicitly return result sets to the client application, so you either have to select <b>into</b> a PL/SQL variable, or process the values in a loop, or explicitly return a ref cursor (or just do the processing in SQL statements within the procedure, without returning anything). I don't know much about T-SQL but I have the impression that in Oracle there is a stronger distinction between SQL (the interpreted query language) and PL/SQL (the compiled programming language) than the equivalents in SQL Server. Saubhik's example above is not PL/SQL (which you asked about) but plain SQL.
Using the example of SQL*Plus, you might use a ref cursor like this:
var r refcursor;
declare
    v_trade_date date := DATE '2010-10-23';
begin
    open :r for
    select *
    from   test_table
    where trade_date = v_trade_date;
end;
print :ror
var r refcursor;
create or replace procedure p (p_out_results out sys_refcursor)
as
    v_trade_date date := DATE '2010-10-23';
begin
    open p_out_results for
    select *
    from   test_table
    where trade_date = v_trade_date;
end p;
set autoprint on
exec p(:r)Edited by: William Robertson on Oct 24, 2010 5:31 PM

How to feed a query using a variable defined as Replacement Path-Query

Scenario description : BI NetW 2004S - InfoCube with the following characteristics Customer, OrderDate, OrderYear and the following KeyFigure Number of Pieces.
Objective: I need a query "QB" that shows how many pieces a set of customers has ordered in the year 2008. The set of customers is defined as all customers that in the previous years (the user can select one or more years) have ordered more than 500 pieces within the same year.
Implementation: In general terms the idea is to build a query "QB" with the characteristic "Customer" that is restricted (filtered) using a variable that is fed by another query "QA" (Replacement Path-Query).
In order to have the selection of customers that for each of previous years (2007, 2006, 2005,...) have ordered more than 500 pieces, in the query "QA":
- I put OrderYear as filter and defined a variable in order to ask the user which year/s he wants to analyse to define the selection
- I put Customer and OrderYear in row
- I put the KeyFigure Number of Pieces in column
- I've defined the following condition: Number of Pieces > 500 with the option Caracteristic Assignment = All Characteristics in the Drilldown Indipendently
Now if I run the query "QA" it works correctly showing me all customers that in the selected years have ordered more than 500 pieces within of the same year.
If I run the query "QB" it shows a correct result only if I enter only one year (for example 2006) in the OrderYear field (coming from the query "QA"); if I enter more than one year (for example 2006 and 2007) the selection of customers showed is not the same defined by the first query "QB": I was expecting to see all customers defined from the first query less all customers that have no ordered any piece in 2008.
Questions
1) Why is query "QA" working on a different selection of customers when the user selects more than one year?
2) Cosidering the scenario and the objective described above do you have any other idea?
Thanks
Ciao
Roberto

Hi Christophe,
it's ok for me if I consider the customer only once in the final selection of customers that feeds the final query, this is my objective.
However as test I've created 2 "input" queries, one related to 2006 and one related to 2007, and then in my destination query I've tried to restrict the customer using 2 variables of type replacement path-query (one attached to the 2006 query and one attached to the 2007 query). Unfortunately when I try to check and save the destination query, Query Designer tells me it is not possible to restrict the characteristic in this way.
Could you please describe me steps you run in to order to restrict a characteristic using more than one variable of type replacement path-query?
Thank you in advance for your answer.
Ciao,
Roberto

BW query designer - create formula using percentage variable

Hello BW Experts!
I am using Business explorer query designer 7.x (based on 7.2) and I want need to create a formula based on 1 KF and a variable that the user would be able to enter when running the query. The variable I want to pass is a percentage that will change each time they run the report and then I will multiply that percentage by the desired KF. Any ideas?
Thanks in advance,
Jim

hi Jim,
you can achieve this using formula variable. This variable is going to be user entry variable and you can use that variable for further calculation, in your case for formula.
thanks.
Wond

Query rule using query variables

Similar Messages

Maybe you are looking for