Re: V17.6 How to getting a newly-related record to load in ORDA

2019-11-19 Thread Chris Belanger via 4D_Tech 
I read my diagram incorrectly… it is going to a NON-PRIMARY key field. What a 
stupid mis-read. 
I will re-work the structure to use the primary key.
Thanks for the tip. 

— dazed and confused,  Chris :)

> On Nov 19, 2019, at 3:17 PM, Chris Belanger  wrote:
> 
> Man, I must be going crazy… yes, it is to the primary key field in [UnitType]…
> They are both UUIDs.
> 
> — Chris
> 
> 
>> On Nov 19, 2019, at 3:13 PM, Chris Belanger > > wrote:
>> 
>> Hi Justin,
>> On checking it again, it is NOT to the primary key in [UnitType].
>> I will try and re-work things to make it the primary key, then.
>> 
>> Thanks for the tip.
>> — Chris
>> 
>> 
>>> On Nov 19, 2019, at 3:33 AM, Justin Carr via 4D_Tech <4d_tech@lists.4d.com 
>>> > wrote:
>>> 
>>> Hi Chris
>>> 
>>> Is the relationship (UnitType) definitely drawn to the primary key field in 
>>> the one table (the one with the underline in the structure editor)? If not, 
>>> then you cannot do what you want. As I said, 4D will always query the one 
>>> table's primary key for the value you enter into the relation, regardless 
>>> of which field the relation is drawn to.
>>> 
>>> cheers
>>> Justin
>>> 
 On 19 Nov 2019, at 6:50 pm, Justin Carr via 4D_Tech <4d_tech@lists.4d.com 
 > wrote:
 
 Hi Chris
 
 Short answer is that if the many table is related to a field in the one 
 table which is NOT the primary key of the one table, the you should 
 ***ABSOLUTELY NOT USE ORDA*** to set the value of the many table field.
 
 There is a horrible bug in ORDA where regardless of which field the 
 relation is drawn to in the one table, it will always locate the one 
 record by querying on the primary key field of the one record using the 
 value you have entered into the many field.
 
 Worse still, when you save the many record, the value you have entered in 
 the related many field will automatically and silently be changed to the 
 related one field value of the now incorrectly loaded one record, thus 
 permanently linking the wrong two records together without any way of 
 knowing that it has happened or of how to undo it!!
 
 To the best  of my knowledge this bug exists in all versions of 4D since 
 ORDA was introduced, on both Mac and Windows, and both 32- and 64-bit.
 
 Regards
 Justin
 
> On 19 Nov 2019, at 6:16 pm, Chris Belanger via 4D_Tech 
> <4d_tech@lists.4d.com > wrote:
> 
> I have a challenge,
> I have a CBOX technique that lets me set the correct related KEY into a 
> record’s field.
> It sets the correct value.
> But that related record is not ‘loaded’ after this correct value is 
> loaded into that field.
> 
> For example:
> 
> Two tables (in classic 4D nomenclature)
> [Units][UnitType]
> Many-to-one relation is  [Unit]UType
> 
> In ORDA, this relation is defined as  Units.UnitType
> 
> (   Units.UType  is the foreign key to the [UnitType] master record   )
> 
> When the record is first loaded, Units.UnitType is the correct — it has 
> the related master record from [UnitType]
> 
> However, If Units.UType is ever set to another unique key from the 
> [UnitType] table, the related record is not re-loaded; and Units.UnitType 
> is null {i.e. no related master record}.
> 
> 
> I do not see any way to trigger the re-load [i.e. CORRECT load] for the 
> related record  Units.UnitType  {the relation name for Units.UType’s 
> many-to-one to [UnitType]  }
> 
> ——
> 
> Is there a way to trigger the related ONE record to re-load in ORDA?  
> [i.e.  Units.UnitType to be correctly showing the [UnitType] record]
> 
> Confused?
> 
> Thanks,
> Chris
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  
> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=utlfdnTMt5rhAY%2FU0XmUjszk9IpEBlP2CRC0zYHGIJg%3D&reserved=0
>  
> 
> Options: 
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=Et1yUOqJN2dh1sbRZkuYuriYl%2BzB76%2BGRGszjAdkYE4%3D&reserved=0
>  
>

RE: V17.6 How to getting a newly-related record to load in ORDA

2019-11-19 Thread Dennis, Neil via 4D_Tech 
> There is a horrible bug in ORDA where regardless of which field the relation 
> is
> drawn to in the one table, it will always locate the one record by querying on
> the primary key field of the one record using the value you have entered into
> the many field.

Justin,

I just ran a couple of tests of this issue in a new structure (4D v17r5, 
Windows 10). I cannot reproduce the results you are seeing

Test 1:

Table_1 -> Table_2 not using primary keys at all
ORDA query Table_1 on other key follow relation to Table_2 (again that 
doesn't go to primarykey)
Success

Test 2:

Table_1 -> Table_2 not using primary keys at all
ORDA query Table_2 on other key follow relation to Table_1  (again that 
doesn't go to primarykey)
Success


Neil





























Privacy Disclaimer: This message contains confidential information and is 
intended only for the named addressee. If you are not the named addressee you 
should not disseminate, distribute or copy this email. Please delete this email 
from your system and notify the sender immediately by replying to this email.  
If you are not the intended recipient you are notified that disclosing, 
copying, distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

The Alternative Investments division of UMB Fund Services provides a full range 
of services to hedge funds, funds of funds and private equity funds.  Any tax 
advice in this communication is not intended to be used, and cannot be used, by 
a client or any other person or entity for the purpose of (a) avoiding 
penalties that may be imposed on any taxpayer or (b) promoting, marketing, or 
recommending to another party any matter addressed herein.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: V17.6 How to getting a newly-related record to load in ORDA

2019-11-19 Thread Jeremy French via 4D_Tech 
What is a “CBOX” technique”?

> On Nov 19, 2019, at 3:16 AM, Chris Belanger via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> I have a CBOX technique that lets me

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: V17.6 How to getting a newly-related record to load in ORDA

2019-11-19 Thread Justin Carr via 4D_Tech 
Hi Chris

Is the relationship (UnitType) definitely drawn to the primary key field in the 
one table (the one with the underline in the structure editor)? If not, then 
you cannot do what you want. As I said, 4D will always query the one table's 
primary key for the value you enter into the relation, regardless of which 
field the relation is drawn to.

cheers
Justin

> On 19 Nov 2019, at 6:50 pm, Justin Carr via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Hi Chris
> 
> Short answer is that if the many table is related to a field in the one table 
> which is NOT the primary key of the one table, the you should ***ABSOLUTELY 
> NOT USE ORDA*** to set the value of the many table field.
> 
> There is a horrible bug in ORDA where regardless of which field the relation 
> is drawn to in the one table, it will always locate the one record by 
> querying on the primary key field of the one record using the value you have 
> entered into the many field.
> 
> Worse still, when you save the many record, the value you have entered in the 
> related many field will automatically and silently be changed to the related 
> one field value of the now incorrectly loaded one record, thus permanently 
> linking the wrong two records together without any way of knowing that it has 
> happened or of how to undo it!!
> 
> To the best  of my knowledge this bug exists in all versions of 4D since ORDA 
> was introduced, on both Mac and Windows, and both 32- and 64-bit.
> 
> Regards
> Justin
> 
>> On 19 Nov 2019, at 6:16 pm, Chris Belanger via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> I have a challenge,
>> I have a CBOX technique that lets me set the correct related KEY into a 
>> record’s field.
>> It sets the correct value.
>> But that related record is not ‘loaded’ after this correct value is loaded 
>> into that field.
>> 
>> For example:
>> 
>> Two tables (in classic 4D nomenclature)
>> [Units][UnitType]
>> Many-to-one relation is  [Unit]UType
>> 
>> In ORDA, this relation is defined as  Units.UnitType
>> 
>> (   Units.UType  is the foreign key to the [UnitType] master record   )
>> 
>> When the record is first loaded, Units.UnitType is the correct — it has the 
>> related master record from [UnitType]
>> 
>> However, If Units.UType is ever set to another unique key from the 
>> [UnitType] table, the related record is not re-loaded; and Units.UnitType is 
>> null {i.e. no related master record}.
>> 
>> 
>> I do not see any way to trigger the re-load [i.e. CORRECT load] for the 
>> related record  Units.UnitType  {the relation name for Units.UType’s 
>> many-to-one to [UnitType]  }
>> 
>> ——
>> 
>> Is there a way to trigger the related ONE record to re-load in ORDA?  [i.e.  
>> Units.UnitType to be correctly showing the [UnitType] record]
>> 
>> Confused?
>> 
>> Thanks,
>> Chris
>> 
>> 
>> **
>> 4D Internet Users Group (4D iNUG)
>> Archive:  
>> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=utlfdnTMt5rhAY%2FU0XmUjszk9IpEBlP2CRC0zYHGIJg%3D&reserved=0
>> Options: 
>> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=Et1yUOqJN2dh1sbRZkuYuriYl%2BzB76%2BGRGszjAdkYE4%3D&reserved=0
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  
> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=utlfdnTMt5rhAY%2FU0XmUjszk9IpEBlP2CRC0zYHGIJg%3D&reserved=0
> Options: 
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cf5d2127a009c404dfd8008d76cd89513%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=Et1yUOqJN2dh1sbRZkuYuriYl%2BzB76%2BGRGszjAdkYE4%3D&reserved=0
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: V17.6 How to getting a newly-related record to load in ORDA

2019-11-19 Thread Justin Carr via 4D_Tech 
Hi Chris

Short answer is that if the many table is related to a field in the one table 
which is NOT the primary key of the one table, the you should ***ABSOLUTELY NOT 
USE ORDA*** to set the value of the many table field.

There is a horrible bug in ORDA where regardless of which field the relation is 
drawn to in the one table, it will always locate the one record by querying on 
the primary key field of the one record using the value you have entered into 
the many field.

Worse still, when you save the many record, the value you have entered in the 
related many field will automatically and silently be changed to the related 
one field value of the now incorrectly loaded one record, thus permanently 
linking the wrong two records together without any way of knowing that it has 
happened or of how to undo it!!

To the best  of my knowledge this bug exists in all versions of 4D since ORDA 
was introduced, on both Mac and Windows, and both 32- and 64-bit.

Regards
Justin

> On 19 Nov 2019, at 6:16 pm, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I have a challenge,
> I have a CBOX technique that lets me set the correct related KEY into a 
> record’s field.
> It sets the correct value.
> But that related record is not ‘loaded’ after this correct value is loaded 
> into that field.
> 
> For example:
> 
> Two tables (in classic 4D nomenclature)
> [Units][UnitType]
> Many-to-one relation is  [Unit]UType
> 
> In ORDA, this relation is defined as  Units.UnitType
> 
> (   Units.UType  is the foreign key to the [UnitType] master record   )
> 
> When the record is first loaded, Units.UnitType is the correct — it has the 
> related master record from [UnitType]
> 
> However, If Units.UType is ever set to another unique key from the [UnitType] 
> table, the related record is not re-loaded; and Units.UnitType is null {i.e. 
> no related master record}.
> 
> 
> I do not see any way to trigger the re-load [i.e. CORRECT load] for the 
> related record  Units.UnitType  {the relation name for Units.UType’s 
> many-to-one to [UnitType]  }
> 
> ——
> 
> Is there a way to trigger the related ONE record to re-load in ORDA?  [i.e.  
> Units.UnitType to be correctly showing the [UnitType] record]
> 
> Confused?
> 
> Thanks,
> Chris
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  
> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cad4c01f6c81f44014ba608d76cc8d450%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=LFYdvJLcBHQeE1DrCsTMNgHcMHrJz9KLWyG7MATewUk%3D&reserved=0
> Options: 
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=01%7C01%7Cjustincarr%40geniesolutions.com.au%7Cad4c01f6c81f44014ba608d76cc8d450%7Cf9523ca0a897457dac3a9b46a9648991%7C0&sdata=Vtu4KP5emmfMa7hTiSXxA5Hk6mt1%2B3x18Lw4Wyz9sGk%3D&reserved=0
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**