"Optional" Relationship Names

Moderators: Phil Winkler, Graham Smith, Pete Tabord

"Optional" Relationship Names

Postby Graham Smith » Fri Jan 13, 2017 3:24 pm

This pertains to an app in 1.53 but probably applies to every version...

Many moons ago, we had a lengthy discussion about "optional" relational names and most of the most experienced people agreed that they really should be mandatory. There was an even longer discussion that followed about whether or not they needed to be unique if different forms were involved. Some said yes but I said no because the engine (at that time the discussion was DFD/DFW) should be able to distinguish. Explanation follows:
Code: Select all
Forms: JanInv2015 | JanRec2015
Relationship: _JanInv | _JanRec

Form: JanInv2016 | JanRec2016
Relationship: _JanInv | _JanRec

I would not expect to see any problem with this because from JanInv2015, the only relationship that can be "seen" is a relationship to JanRec2015. IOW, the engine looks at all the relationships between the two files, then looks at the optional name, so the only relationship that would be seen is _JanRec. To my knowledge, I have never seen anything that didn't appear to work that way - until this morning.

The files I am speaking of are holder files that I'm using to find some discrepancies in some data. The database they were in was slightly out of date so I got a fresh copy and installed the holder forms and relationships in it. What I found was that from JanInv2015, the relationship _JanRec was taking me to JanRec2016. IOW the wrong form.

As I said, I had installed the relationships from the older database so I removed them and put them in by hand and after that everything was fine. I can think of no reason on earth why this could have happened. It's as if the act of installing the relationships resulted in them getting cross-linked.

If all of this is confusing, well it's been one of those mornings. I'm chasing my tail trying to find a data discrepancy and run smack into this which led me down the wrong path for an hour.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Re: "Optional" Relationship Names

Postby Adrian Jones » Mon Jan 16, 2017 12:36 pm

All I can think of with this is -- are you sure?

Sure that you've gone to the wrong form, or sure that there isn't a relationship between the 2015 and 2016 versions.

With these sorts of form and relationship names, it is very easy to miss some naming issue, esp when, I'm guessing, the 2016 forms were probably created out of the 2015 versions, and the old relationships may have been copied.
User avatar
Adrian Jones
 
Posts: 2000
Joined: Tue Sep 11, 2007 2:38 pm
Location: Cornwall, UK
Has thanked: 5 times
Been thanked: 4 times
 

Re: "Optional" Relationship Names

Postby Graham Smith » Mon Jan 16, 2017 1:08 pm

Adrian Jones wrote:All I can think of with this is -- are you sure?

Yup.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Re: "Optional" Relationship Names

Postby Adrian Jones » Tue Jan 17, 2017 9:54 am

What does the data model show?
User avatar
Adrian Jones
 
Posts: 2000
Joined: Tue Sep 11, 2007 2:38 pm
Location: Cornwall, UK
Has thanked: 5 times
Been thanked: 4 times
 

Re: "Optional" Relationship Names

Postby Graham Smith » Tue Jan 17, 2017 6:27 pm

Adrian Jones wrote:What does the data model show?

It showed that from JanInv2015, the relationship _JanRec points to JanRec2016. Since I deleted and recreated the relationships, there's no way to go back and look at it now, so that's about all I can tell you.

I can only assume that something screwed up when I installed the forms and relationships. Like I said, I've never seen anything like this before, but I do recall Pete saying in the past that every relationship should have it's own unique name for just this reason and never understood how it could happen.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Re: "Optional" Relationship Names

Postby Adrian Jones » Wed Jan 18, 2017 6:53 am

I've never seen what you describe, and would not advocate completely unique relationship names.

I've tried -- probably unsuccessfully -- to encourage the use of relationship names that have meaning, specifically to show the nature of the relationship at the point of use.

So in the case of a one to many, the relationship name indicates which side is the one and which side is the many, underlining characteristics of the match fields. In a sibling relationship, the name indicates the parent table, and so on.

My understanding and experience -- as is yours -- is that the relationship name is in the context of the related tables, at which point it is unique (or should be). There should not be two relations from Customer to Invoice called "SeeInvoices", and I argue you can think of the full relationship name as "Customer.SeeInvoices". If there is to be a second relationship that uses the same match fields, for which there are uses, I stick a letter on the end of the name.

Should there be an 'ArchivedCustomer' table that continued to look at the (non-archived) Invoice table, I would not expect continuing to use the same relationship name to that table to be an issue, again because it really is 'ArchivedCustomer.SeeInvoices' (struggling with the example, but I hope you get the point).

I have probably been using this sort of convention and relying on this understanding for around 20 years! Of course, it may well be that my relationship names happen to be unique anyway, but it does sound to me like something else is going on with your system. Should it be some kind of corruption, it would be a pity to have to rethink some aspect of FF development based on bad coding in the product!
User avatar
Adrian Jones
 
Posts: 2000
Joined: Tue Sep 11, 2007 2:38 pm
Location: Cornwall, UK
Has thanked: 5 times
Been thanked: 4 times
 

Re: "Optional" Relationship Names

Postby Adrian Jones » Wed Jan 18, 2017 6:55 am

BTW, I should say that FF is so much more reliable and stable than DfW, where I had to get into all sorts of habits just to tiptoe around the stability issues it had.
User avatar
Adrian Jones
 
Posts: 2000
Joined: Tue Sep 11, 2007 2:38 pm
Location: Cornwall, UK
Has thanked: 5 times
Been thanked: 4 times
 

Re: "Optional" Relationship Names

Postby Pete Tabord » Wed Jan 18, 2017 12:23 pm

The 'set of both form names and the target relationship name should be unique, almost as if it were a compound index.

There is no problem using something repeating like n/a for a relationship that is not intended for use - lots of people do that.

If FF for any reason gets confused, it will use the first matching record for the two forms. So, if something is working by luck (no relationship name) changing the order of the relationship records will change processing.

I am suspicious (no more than that) about having duplicate names but I've never had a concrete case to confirm the suspicion.

Where it could be a potential problem is by accidentally having a duplicate name for two relationships from the same form with the same fields but a different target form. It seems to me that in such a case it is possible that the relationship which is picked up first will be used, and then should the order of relationships records change then the wrong target form could be used.

In other words, I'm convinced it tests that the fields match, and it certainly only looks for relationship records which have the 'from' form name either as the left or the right form, but in the case of a duplicate name(which most naming conventions would prevent anyway) I'm not convinced that, if it finds a name, that it checks the target form is the intended one. It's not going to come up very often, but it is not impossible either.

There are changes to the code in 2.0 to cater for external forms, where it also reads relationships from the source database. Although it won't do anything with them, it just stops endless 'unknown relationship' errors - the direct drivers aren't intended to provide full update facilities, they are for reading legacy (archived?) data which saves bringing all the last 30 years of old rubbish in to your shiny new FF app.
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 

Re: "Optional" Relationship Names

Postby Graham Smith » Wed Jan 18, 2017 12:59 pm

Both of you are saying what I always believed so what I saw was some kind of anomaly. I'm guessing that something weird and unexpected happened, possibly due to something odd I did as I was working extremely fast.

The only thing I could think of was to question if the relationship form uses any kind of what we used to call "pcode" in DfD days. If it does, then what would be the effect of installing the relationships before the forms. Let me explain...

To copy the forms from one db to another, I used my own home grown set of tools that creates an install.diw which can be used by another db. Relationships are exported from the source and imported into the target. I have never paid any particular attention to the order in which I do these two things because I never thought it would matter. But perhaps there is a particular circumstance when names are similar where something like this could happen.

The only other alternative I can come up with is that I have finally lost what little is left of my mind.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 
 

Return to Ffenics 1.x

Who is online

Users browsing this forum: No registered users and 9 guests

cron