Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6911 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

If I have understood you correctly, I can't confirm your observations. Look at my small example that works.

Maybe there are some missing fields on your web layouts?

And there is something else: FM 7 is very precise on relations. Field match means that key fields must match char by char, case-sensitive. Additional spaces etc. in one of the keys already have a mismatch as consequence. So you should also check your keys used for the relations.

I know only that there are problems if one has self-join relations and lookup fields based on those self-join relation that copy a value of a calculated field. This should still work, but performance is poor.

test_lookup.zip

Posted

I have not tired your example yet, but we are not using xslt to create the xml query. The XML that we are using simply to create and push a value to a new record is:

http://<<Serveraddress>>/fmi...;VALUE&-new

This creates a new record without any problem, but no lookups or other items that intereact with a referenced FMP DB seem to pull over. Lookups and other items do work on tables that are in the main FMP DB

Posted

I have added two additional XSL files to my example, see attachment. If you call test_lookup3.xsl, it shows you three links. The first link adds a record in fmresultset grammar, the second in the FMPXMLRESULT grammar (as in your example link above), and the third shows you all records that have been added to the database.

The XML queries work with both XML grammars, and the lookups are done as they should be.

P.S. My example also shows that it doesn't matter if you reference a table within the same database or in another.

Could it be that you have several uncleaned file references to the external database that mess up the lookup? Could it be that you reference the wrong table occurence in your relationships graph?

test_lookup.zip

Posted

Are you using FMPXMLRESULT grammar?

If so, try the fmresultset grammar. There is a bug in the FMPXMLRESULT grammar which causes the behavior you describe.

You can overcome the bug by setting the option (in the relationship) that allows for the creation of records in the relationship, or on your layouts, express the related fields as calculation fields instead, i.e. create calculation NEW FIELD fields that are is your TABLE::FIELD, and put NEWFIELD on your layout.

  • 8 months later...
Posted

I am having this same exact problem with CWP using FX.php.

I have two database files: a directory file, and a signup file. The directory contains contact information for our members. In the signup file, a member enters their number (online - a page using FX.php) and a record is created. Fields that are stored in the directory are looked up so the user doesn't have to enter it again.

In this two file setup, the lookups do not occur. In fact, NOTHING that relies on the relationship between the two files works (calculations, scripts, related fields, etc.). Both files have the same user and password for web access, and I even tried giving the account full access, to no avail. I know the relationships are good because everything works within the FileMaker program.

The interesting thing is, when I do this with all the tables in one file, it works perfectly!

What is going on in the two file setup that makes this not work?

Some additional notes:

- This must stay a CWP solution.

- This must use the two file architecture. We have many auxiliary projects that use the directory information, and we do not want to put everything in the directory file. Too many people working at the same time.

This topic is 6911 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.