Relation works in fm 8.5 but not in fm9

[Claus Lavendt]

Hi

I have a strange problem.

As you can see in the attached fm file, this is a simple technique.

In fm 8.5 you can see all the records in the left portal. When you click one of them, they are sent to the right portal and disapeares from the left one.

Now, if you open the file in fm9, you can only see records on the left portal, if one or more is on the right portal.

It uses 2 relationships:

interface = data right

interface = data left

interface ≠ data right

Anyone have a clue ??

... it is a very urgent problem !!

[Søren Dyhr]

Somehow is there something wrong with downloads at present, but fm9 is much more intolerant to key type mismatches, so if a multiline key is involved must both sides be text!

--sd

[comment]

if a multiline key is involved must both sides be text!

Let's not go to extremes. AFAIK, the issue applies only to ≠ relationships. The field types CAN remain as they were. The only change is that the multi-line key field (text), when matched against a number field, must contain a number - any number - at all times. Otherwise it's considered empty and the relationship does not work.

[Søren Dyhr]

Let's not go to extremes. AFAIK, the issue applies only to ≠ relationships

You mean, exceptions leaves bigger traces in your memory, however did I notice Vaughan, some years ago before even betatesters have had access to fm9, said that he always kept both sides of a relationship in the same types ... I paid attention becasue it back then were more a rule of thumb than a necessity!

--sd

[comment]

Sure, you can be a purist and convert all your key fields to text. But there are prices to pay, since text does not sort the same way as numbers, so now you will have problems with > type joins. I would call that going to extremes.

And what about a list of dates? Are you going to keep a text version of every date field, just to match a multiline?

Hopefully, FMI will fix this and revert ≠ relationships to their previous behavior.

[Søren Dyhr]

Are you going to keep a text version of every date field

I thought I'd only talked about multilinekeys, however am I seen making dates via Int(theDate) in CF's ...but would prefere repeater-calc's with Get(CalculationRepetition) ...if the repeating calc-field is defined as date then will it link correctly.

However can Dwindling also be done entirely ignoring non-equi's:

http://www.nightwing.com.au/FileMaker/demos7/demo703.html

...perhaps an overhaul is required, in order to have fewer global fields perhaps - but anyway.

--sd

[comment]

I thought I'd only talked about multilinekeys

So did I. In the context, I meant "Are you going to keep a text version of every date field that links to a multi-line". I prefer repeating calcs with a Date result too, but it's not always possible, and a multi-line text linking directly to date is a valid method, IMHO (unless you're mixing various date systems).

[Søren Dyhr]

but it's not always possible

Enlighten me, something I'm forgetting??

--sd

[comment]

Nothing specific comes to mind, but there are things that are possible with a custom function and not with a repeating field (and vice-versa). Moving from 'possible' to 'practical', if I can get results using List ( related::Datefield ), I'll take it.