VLink Mess Re: FindLinkedSingle ?

[Ed Kleban]

Nope. The list below won't work.   I just couldn't figure out before "Why in
the world would you pass TableA and TableB arguments to FindLinked when the
Vlink already knows what the tables are?"

The answer of course is that it doesn't know what the tables are.  a
VBinaryLink knows, but the FindLinked method has been defined to work on all
types of Vlinks including Foreign Keys and presumably ObjectPtr links.

This is probably the source for what has resulted in such a confusing mess.
Now I understand.

I appreciate and admire the goal of having a single set of calls at the
VLink method that are uniform and universal.   On the other hand doing so
has resulted in a call that has all sorts of messy problems.

What happens if you specify unrelated tables for the link?  This is just
asking for trouble to have a method that requires you to respecify the
tables to use when that information is inherent in, or has been previously
defined already for, the link.

I discovered this when I went looking for the "TableA", "TableB",
"LeftPower", and "RightPower" properties in class VLink and discovered...
Doh!  They're not there!   I then went looking for them in the VBinaryLink
class documentation and discovered that they weren't there either ...
although this may simply be a documentation oversight.

I'll have to think about this some more Ruslan.  The proposed methods below
would work certainly, but only if defined for class VBinaryLink, not for
VLink or VLink2.  The solution I was proposing is nowhere near as elegant as
I had thought it was.

Time for more sleep :)

Nite!
--Ed 

On 12/11/05 11:19 PM, "Ed Kleban" <Ed at Kleban.com> wrote:

> Gack!
> 
> There's no FindLinkedSingle call in the API.
> 
> Any reason why not?
> 
> How much of our discussion from earlier today is it worthwhile for me to put
> on Manits Ruslan?
> 
> Let's see... the possible list includes:
> 
> 
> 1)     aVLink.Link2Records( leftTableRecID, rightTableRecID )
> 2)     aVLink2.LinkRecords ( leftTableRecID, rightTableRecID )
> 
>     Actually, since RB has supported paramArray arguments for quite some time
>     you could even support:
> 
> 3)     aVLink.LinkRecords ( paramArray inOrderedLinkRecIds as Integer )
>  
> 
> 4a)     FindLinked( inRecID as Integer, inResult as EVLink2Result )
>             as VArraySet
> 
> 4b)     FindLinked( inSet, inRecId, inResult ) as VArraySet
>     
> along with:
> 
> 5)     EVLink2Result.kLeftLink =
>             EVRecursionDirection.kFromChildToParent
> 6)     EVLink2Result.kRightLink =
>             EVRecursionDirection.kFromParentToChild
> 
> and now I guess:
> 
> 7)     FindLinkedSingle( inRecId, inResult ) as Integer
>             // Returns RecId from inResult side
> 
> 
> Of these proposals, I'd say:
> 
> 4a, 4b, 5, and 6 are Low priority since they provide clarity but no new
> functionality.
> 
> 1 or 2 would provide both an efficiency gain and result in cleaner code.
> Either would do.  I don't know that VLink2 is defined for V4RB
> 
> 7 similarly offers a minor efficiency gain and a little cleaner code.
> 
> I wouldn't consider any of these high priority I guess.
> 
> 
>