> On 2014 Dec 1, at 11:16, John Weinshel <[email protected]> wrote: > > I'm not quite following. Is Pqr in Table A? If so, its indexing and/or > storage is not the problem.
Well, that’s what I thot as well, but I don’t do this sort of thing very often, so my confidence level was low. Armed with your reassurance, I went back and took another look at it and discovered that I was trying to connect Pqr with the wrong value from Table X (not Xyz, as it should have been, but rather the primary key for Table X). Once I established the proper link, all the data showed up in the portal just as they should have. Thanks for putting me on the right track, John. > > If Pqr is in Table X, then, yes, it must be indexable. > > If it's in Table A, can you describe what happens, i.e., what you mean by 'it > doesn't seem to be working'? > > If it's in Table A, you may be running into a situation where the the key can > evaluate to null or empty, and that can break a TO. This was a change > introduced in Filemaker 9 (the ESS release), in order to comport more with > SQL rules. > > John Weinshel > > From: "Richard S. Russell" <[email protected] > <mailto:[email protected]>> > Reply-To: FileMaker Pro Discussions <[email protected] > <mailto:[email protected]>> > Date: Mon, 1 Dec 2014 03:28:34 -0600 > To: <[email protected] <mailto:[email protected]>> > Subject: Creating a Relationship Using a Global Field > > So here in Table A I have a numeric field, Abc, and a global field, Ghi. > > Over there in Table X I’ve got a numeric field, Xyz, an indexed decimal > number. > > What I’m trying to do is have a calculated field in Table A, Pqr = Abc + Ghi > / 1000, link to Xyz. Obviously, Pqr can’t be stored, because it relies on a > global field for part of its value. Not being stored means it can’t be > indexed. Nonetheless, Xyz is indexed, and I thot that was all it took to > establish a valid relationship. > > It doesn’t seem to be working, tho. Am I missing something, or is this just > not gonna work?
