many-to-many calculation doesn't work

[Limulus]

hi all,

i've made a many-to-many db by creating a join file for two base tables/files (they use unique ID's for records which are joined in the join file - i'm a newby and this is textbook). When i change some data in one of the base tables, my join file isn't updated. So a portal in the other base-file isn't updated as well. As this is fundamental for relational db's i must be doing something completely 'n uterly wrong (or the FileMaker company is ...). Ideas anyone?

[danjacoby]

One thought: Are you using any stored calculations? If so, make 'em unstored.

[Ugo DI LUCA]

Not really. If you're using lookup fields for instance (which is correct depending on the "job"), this behaviour would be classic and accurate.

What would you like to be updated in the Line Item ?

Could you be more specific about your Problem ?

[Limulus]

Thanx danjacoby,

done that, but the same result applies. I even tried lookups, and i'm trying to find automatic relookup or something. But i can't believe that should be necessary (no, ... it couldn't be, that's so access like)

[Limulus]

Hi Ugo,

2 be more specific (hey, i'm dutch ...). Suppose i've got bikes, and accessories. I want to list accessories associated with a bike model. So, i have a view on bike specifics with a portal for accessories. The portal has entries which list all accessories. When i enter an accessory on a new portal line, i in fact create an entry in the join file with bike ID, accessory ID. I also use calculation fields in the join file to display accessory name (f.i.). When i change accessory name in the accessory file, my joinfile calculation isn't updated. So, my portal in the bike (view) isn't update either.

Hope i'm making sense here ...

Thanx for looking into this

[-Queue-]

Are you using calculation, auto-enter calculation, or lookup fields to display the related fields?

[Ugo DI LUCA]

Well,

It should be updated then. What relationship are you using for the calculation ? It should be a relationship Accessory_ID::Accessory_ID.

Are you sure it's a calculation. Isn't it a lookup field ?

[Limulus]

I rechecked the setup. The bike file uses a portal of the join-file data. The join-file uses a relationship with accessories (a-ID, a-ID). The join-file uses unstored calculations to display extra data about accessories (like name et cetera).

It should work, i guess.

[Ugo DI LUCA]

Sure it should.

Check that the field formats (num/text,..) you used for the Ids are equal for both files

[Ugo DI LUCA]

Wait a minute. The Portal doesn't update but the Line Item does ?

[Limulus]

Field formats are the same (numeric).

Ai. It might be though that one of the relationships has a flaw (oh shame ...). Yep, the 'newbie realisation shame' has struck again. It still doesn't work, but i'm on track.

Thanx folks, and you too Ugo!

[-Queue-]

Can you post your files for us to doublecheck?

[Limulus]

Yes i could,

but i would have to post 29 interrelated files (this monster creates automatically a website from db with the help of some homegrown Python script) - and holds the firms accounting too - -). And i'd like to see this particular bit work first (before the sun rises again over the Dutch flat wetlands).

Spiffy stuff FileMaker, once you give it a spin.

[Ugo DI LUCA]

Save the 3 related files as clone file and attach them here.

Now, is that Accessory Name coming from another relationship ?

[Limulus]

helas, i've tried preparing clones, but there're so many more relationships with seperate files it would take some serious preparation to send it. But thank you for your kind offer. I will sleep soon, it's around 1:30 at night here -)

[-Queue-]

If the relationships aren't involving the fields you're having trouble with, then we don't need those files anyway. It's fine to leave the relationships that don't effect it as broken and just send the few that are currently causing the most grief.