I have files A and B and a relationship in A to access global fields in B.

The relationship is between gA and gB, two global text fields.

I've done this many times. This time it is not working. From A I can't read the global fields in B.

The files are not corrupt.

I've tried to create another relationship between the same fields but it is not working too.

All the other relationships (between standard or calculated fields) work fine.

All the other global-to-global relationships in the other files of the solution work fine.

Any idea?

Thanks

Paolo

Hey Paolo,

Could it be that there are zero records found in one of the files?

Do the globals have a value entered?

Succes,

Ernst.

I didn't think you could really use globals on the right side of the relationship because they are not indexed.... Can anyone else confirm this?

Global to global relationships work fine for passing global values. You can't get non-global values though.

ernst said:

Could it be that there are zero records found in one of the files?

Do the globals have a value entered?

Ernst.

both files have a non empty found set (I forgot to say this in my first post)

the globals do not have values entered. does this matter?

Hi Paolo,

>>the globals do not have values entered. does this matter?

Actually it doesn't matter. And zero records found doesn't matter either. Just tried both. Sorry for this bad advise.

Maybe a corrupted file?

Ernst.

Well, live and learn! I though you were both crazy, Ernst and Paolo. Just tried a global-global relationship and you're not!

BUT my gA-gB works no matter what the values in them. e.g. I tried 'Z' in one and 'W' in the other and still get the value out of gC. It also works with blank values in gA and gB.

This sort of situation scares me. This Global-Global relationship should not work but it does .... but does it always? What do FMI say about it?

Paolo, how can you be certain your files are not corrupt?

Invalid and global relationships, as far as I know, have always been useful for passing globals. Since globals can't be indexed, I guess it just assumes that the values are valid when you call it. I have also seen speed tests that show invalid/global relationships to be much faster than valid ones at passing data. And somewhere around here is a method for displaying a button in Find mode only, using a portal based on an invalid relationship, which appears to assume its validity while in Find mode, when no relationships are really valid.

In FM6, two tables with *any* relationship between them are allowed to pass globals between them - the relationship is meaningless, it can be invalid or whatever.

In FM7, this (silly) restriction was removed, you can access globals from any table - no relationship is required.

I'm sure the files are not corrupted.

By the way: accessing globals with invalid relationships is faster that with valid ones.

Paolo, that was a sort of technical question. I thought maybe you'd found a way of checking for corruption.

I would NEVER (well rarely) use an 'invalid' anything for anything but fun. Reason? Many years ago, when computers were real and the software actually worked, many people had been using an invalid function in some package; I forget what or why. The supplier fixed the 'error' and suddenly dozens of programs didn't work properly and nobody had any comeback.

One more thought: perhaps the globals are realy not globals. I would check the field definitions again to make sure that what is, is and what is not, not is; Good luck. Greg W.

"If what we believe does not lead us to solution, perhaps we believe is mearly an illusion."

invalid relationships are a common technique (not a bug) to access globals in other files and pass data between scripts in different files.

The term "invalid" in this case is misleading. There is nothing to "fix" and this is an appropriate way to pass global values.

I totally disagree with both of you. If the specifications for FMP say you cannot/should not use unindexable fields on the RHS of a relationship than doing so is, by definition, 'invalid'. The fact that they work is an accident and could well be changed by another accident, so that it no longer works.

I'd love to hear what FMI have to say about this.

Depending upon the old notion that T/F/True/False/Y/N/Yes/No would work in number fields as booleans is the same principle. In FM7, this is no longer supported. Luckily in FM7, globals are 'valid' no matter what anyway but your point is a valid one, Paul.

I tend to think that change may require reworking a solution, regardless - but hopefully the change will be worth it.

how do you access a global field in a related file?

You can get a global value through ANY relationship to the other file.

Oldfogey, you are mistaken and hung up on a particular reading of the word invalid. This behavior is not an accident, it has been there since FM3, it its still there in 7.02, it is fundamental to how Filemaker works, it is required for scripted find operations, and it is not going to go away. It is no different than entering -1 in one side of a relationship and 1 on the other side. There no matches, but you can still pass a global.

I'm sorry but I'm not hung about 'invalid'. It just happens to be the most precise description of this phenomenon.

If you define a relationship between two globals, FMP says it will not work. I don't care what you call it, if you then use such a relationship, it is not within the specifications as defined by FMP. It is really no different from entering a word in a date field. There are, in fact, some funny situations where you can enter incorrect data in a field and it works - but I wouldn't want to depend on it.

I was quite surprised to see that 1::-1 will pass globals.

I'll accept your statemement that "You can get a global value through ANY relationship to the other file." I would love to use it. As for "it is fundamental to how Filemaker works", come on, pull the other one.

I am quite happy to continue this discussion but it is probably boring for most people. I am going to take this up with FMI because I quite often use the validity, or otherwise, of relationships to determine values/actions/etc.

1. An example of an invalid relationship is if a one of the tables or fields is missing.

2. Think a little harder about find mode, and what data you can see in find mode, and how you can pass data to scripted finds. Think very carefully about this.

3. If you enter a bogus field name in a calculated field definition, you CANNOT close the field definition. If you enter globals on both sides of a relationship, you CAN close the relation definition.

"There are, in fact, some funny situations where you can enter incorrect data in a field and it works - but I wouldn't want to depend on it." What; like have a text global hold multiple return separated recordID values, matched to a RecordID number field? No, you wouldn't want to do that.

"I was quite surprised to see that 1::-1 will pass globals."

That's because you are misled by your choice of vocabulary in defining relationship configurations.

That's because you are misled by your choice of vocabulary in defining relationship configurations.

But luckily (?) we have you to straighten us all out, in your understanding, empathetic, logical, respectful and gentle manner ...

First, it is nothing to do with my "... choice of vocabulary". In V6 and earlier, FMP says a relationship to a Global will not work. In my book, that makes such a relationship invalid - no question about my use of vocabulary. What word would you use?

In V7, the warning has disappeared. OK, so the original warning was wrong - dare I say 'invalid'?

By the way, I did take this up with FMI. Would you believe I've had no response?

In Version 4, a Global to Global relationship will return this message:

This relationship will not work because the field (right side of the relationship) cannot be indexed. Proceed anyway?

Ok or Cancel

In FM5 and 6, no such message is produced.

Lee

Hmmm, I received that message many times when using a global for the right-side in a relationship - in vs. 6. I am unsure why you didn't get that message.

Ah man, this is embarrassing. I used a field that was text, that I had labeled as a global. Duh.

You are correct, changing it to a global field did produce the message. The relationship works though.

I had created this file for testing -queue- suggestion of isolating a record by using this type of relationship and the GetField(RecordID).

Lee

I do like our new Graemlins.

They are invalid for setting non-global data, but extremely efficient at passing globals or setting globals (which makes sense since even existing yet currently invalid relationships can be used to pass or set globals, such as a primary to foreign id relationship where the foreign id does not yet exist, but you want to pass the primary id to a global in order to set it). In 7, invalid relationships are no longer as useful since globals are universally accessible between tables without a specific relationship. I agree that it should warn you when creating such a relationship, however.