free_2tak
15th February 2011, 13:27
SELECT cprrp100.*, cprpd400.dsca, tcibd001.dsca, tdipu001.buyr FROM
cprrp100, cprpd400,tcibd001, tcibd200, tdipu001, cprpd100
WHERE cprrp100._index1 = { :cprrp100.plnc, :cprrp100.type} AND
(cprrp100.item refers to cprpd100 and cprpd100.item refers to tcibd200 unref clear and cprpd100.item refers to tdipu001 unref clear) AND
cprrp100.plnc REFERS TO cprpd400 AND
cprrp100.item REFERS TO tcibd001 PATH cprpd100.item,tcibd200.item ORDER BY cprrp100._index1
I have copied the above query from a session. Now i have sopied the same query in Query Data-> new Quey.
But when i do run Query -> execute , it gives the following error:
"unref mode" expected instead of "clear)"
mmurphy2650
15th February 2011, 15:59
I don't think that the Query Data Session allows unref in the REFERS TO predicate. It probably won't like PATH either.
Remove unref and PATH from your Query and you should be OK.
free_2tak
15th February 2011, 16:25
But if we remove unref and path, their significance might be lost right?
I mean do we miss or get more information by removing path and unref?
Could you please let me know the significance of unref and PATH?
Do the query returns same results with unref, path and without them?
mmurphy2650
15th February 2011, 16:45
Check out the syntax in the Programmers Guide here ...
http://www.baanboard.com/programmers_manual_baanerp_help_functions_database_handling_references
It will explain what happens without unref and PATH. I'd test it out and see what your results are.
free_2tak
15th February 2011, 16:53
Can we achieve the functionality of unref and path using Query data?
I mean directly or indirectly?
mmurphy2650
15th February 2011, 17:01
Yes ... you should achieve the same functionality without the unref.
In our environment ...
The value of an undefined reference is filled with a '*' sign, or with 0 for numeric fields.
As far as PATH goes, you should get the same results without it.
Give it a try.
Mike
free_2tak
15th February 2011, 17:22
Thanks for the reply. I have got one more question.
In the query,
SELECT cprrp100.item, | Part Num
cprrp100.prdt, | Release Date
cprrp100.quan, | Ordered Qty
cprrp100.suno, | Buy From BP
tdipu001.prip | Purchase price
FROM cprrp100, cprpd400,tcibd001, tcibd200, tdipu001, cprpd100
WHERE cprrp100._index1 = { :cprrp100.plnc, :cprrp100.type} AND
(cprrp100.item refers to cprpd100 and cprpd100.item refers to tcibd200 and
cprpd100.item refers to tdipu001) AND
cprrp100.plnc REFERS TO cprpd400 AND
cprrp100.item REFERS TO tcibd001
order by cprrp100.suno, cprrp100.item, cprrp100.prdt
In the above query what is the significance of the condition "cprrp100._index1 = { :cprrp100.plnc, :cprrp100.type}"
Please let me know. Much appreciate it...
mmurphy2650
15th February 2011, 18:38
Those are program variables. They are explained in ...
http://www.baanboard.com/programmers_manual_baanerp_help_functions_database_handling_using_program_variables
Not to complicate things, but if you only want to print a certain range of Scenarios and Planned Order Types, you can prompt for ranges in your Query session by appending .f and .t after your field names.
For example, the following query prompts for and only prints items and order dates in the ranges that you enter when you run the Query:
select
tdpur401.orno, | Purchase Order
tdpur401.pono, | Position
tdpur401.sqnb, | Sequence
tdpur401.oltp, | Order Line Type
tdpur401.item, | Item
tdpur401.qoor, | Ordered Quantity
tdpur401.qidl, | Delivered Quantity
tdpur401.qibo, | Back Order Quantity
tdpur401.qiiv, | Invoiced Quantity
tdpur401.fire, | Final Receipt
tdpur401.stsc, | Update Status of Actual Purchase Costs
tdpur400.hdst, | Status
tdpur400.otbp, | Buy-from Business Partner
tdpur400.odat | Order Date
from
tdpur400, | Purchase Orders
tdpur401 | Purchase Order Lines
where
tdpur401.item >= tdpur401.item.f and
tdpur401.item <= tdpur401.item.t and
tdpur400.odat >= tdpur400.odat.f and
tdpur400.odat <= tdpur400.odat.t and
tdpur400.orno = tdpur401.orno