Keith,
Neil is dead on in the case of RELATE MANY - you can access this directly
from the entity via the name of the relation. But you are asking about
RELATE MANY SELECTION where you have a selection of one-records and you
want a selection of all the many-records.
Your example works fine - though you don't need the step of converting to
and from the array:
$clients:=ds.Client.query("Name = :1";"@"+Self->+"@")
$col:=$clients.distinct("PriKey")
EntSel:=ds.Contract.query("to_Client IN :1";$col)
By definition the PriKey should be distinct already but there's no downside
to the command and it will also work for non-distinct values so it's a good
habit to develop.
I would shorten it to a single query line:
$col:=ds.Client.query("Name = :1";"@"+Self->+"@") .distinct("PriKey")
EntSel:=ds.Contract.query("to_Client IN :1";$col)
This doesn't throw an error if the query is empty. And it's two lines of
code to replace 7.
I infer you are retro fitting this ORDA code into an existing form because
of using Self and a process var for EntSel. My experience so far is this is
the less optimal way to implement ORDA. First, classic 4D is probably doing
just fine for this chore so carry on with what you've got. Introducing ORDA
in cases like that usually don't work out great. Your example sort of makes
this point - if you start thinking the way to solve an ORDA problem is to
start converting back and forth between arrays you are probably missing
something new you should be using.
For UI stuff like this that means the object referenced by Self will
ultimately be better handled if you begin using Form. I like to start from
scratch when convert a form: make a new blank form. Copy in the most basic
elements of it and learn to set it up using Form. You will know you're
doing it right when you stop needing to rely on pointers (especially Self)
and process variables to manage forms. I stress "rely on" here. Self is
useful but if you are using ORDA it's the last resort, never the first.
Process vars have a place but rarely - very rarely - for managing a modern
4D form. Learn to use Form instead.
Once you have the basics working, (opening, closing, moving around,
populating static or semi static objects) start adding in the other
functionality. As you do that think about what you trying to accomplish -
what is goal and purpose of the list, listbox, subform, etc. you are adding
in. And how do you accomplish that with ORDA. This is important because
whatever that task is accomplishing it with ORDA will nearly always be a
completely different workflow from accomplishing it in classic 4D. If you
simply paste in what you've been doing it's not going to really change
anything. And if you don't want to really change anything what's the point
of converting to ORDA?
By putting this into a brand new form you eventually get to a point where
you can compare your new approach to the old head to head. And this also
makes it easier to swap out the new form for the old in your code.
Hope this helps.
On Thu, Dec 5, 2019 at 12:00 PM kculotta via 4D_Tech <[email protected]>
wrote:
> Hello,
>
> RELATE MANY SELECTION is a convenient way to get a set of related many
> records.
> Is there a more succinct or efficient ORDA method than the following to do
> the same thing?
>
> // get Contracts for a group of Clients
> ARRAY TEXT($array;0)
> C_COLLECTION($col)
>
> $clients:=ds.Client.query("Name = :1";"@"+Self->+"@") // get the clients
> $col:=$clients.toCollection("PriKey") // make a Collection of Client
> Primary Keys ("PriKey";"..Value..";"PriKey...)
> COLLECTION TO ARRAY($col;$array;"PriKey") // make it an array of Primary
> Keys
> ARRAY TO COLLECTION($col;$array) // back to a Collection of Text
> ("..Value..";"..Value..")
> EntSel:=ds.Contract.query("to_Client IN :1";$col) // search in the
> Collection
>
> Thanks - Keith CDI
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
--
Kirk Brooks
San Francisco, CA
=======================
What can be said, can be said clearly,
and what you can’t say, you should shut up about
*Wittgenstein and the Computer *
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
