I'm wondering about it's usage and if maybe how it's used might have changed from versions befor filemaker 7.

So go to a layout, and initiate the relookup on the field that's the key for the relationship that the lookups get their data through.

Does this only relookup fields that are on the layout?

what happens if i have lookup fields that are from another relationship, I'd assume i need to do the relookup on the field responsible for that relationship too. My situation is one where i've got lookup fields that grab from atleast 2 relationships.

I'm mostly curious about what get's looked up, is it just the fields on the active layout, or all fields that get data by a lookup through that realtionship's key that's being relooked up.

Thanks guys!

A Relookup will update all fields within the current found set that are defined as lookups which use data from a relationship which has the relookup field as its left-hand key. It doesn't matter if the lookup fields are on the layout, as long as they use an associated relationship. If the two relationships use different key fields, then yes, you will perform a relookup in both fields.

cool, that's what I'm looking for.

In my case, if for some reason the customer needs to be changed after items have been put on their invoice, the just the lookups from the customer table get refreshed, and not the lookups that come from the items table, unless i run another lookup on the key for items.

though i guess the origional developer should have just stuck the client info in the invoice fields, rather than the line item fileds. argh!!!

Can you easily change that? I can't think of any reason why having client info in a line items file would be beneficial.

i'd like to change it, except that the transaction report runs out of there and we allow for searching by client, staff member, and the artist who created the object. It actually only holds the client, staff and artist's id numbers and except for the artists full name, nothing else. relations to the invoice are used for the client info and the staff info that is shown on the report.

It's kind of a dirty way to make it easier to search by those 3 pieces of info cause how would i search the line items file for items a staff member sold, or that a certain client bought with out looking at the invoice file first. Not that staff kmember commision is neccesary, but there is a commision paid to the artist.

Is the search specific to each possibility or can you combine, say, a search for a client and artist? If the searches are independent, then you could go to the record in the specific table (e.g. the particular client record) and Go to Related Record from there. But it would depend on how things are set up. For clients, it seems like it should be fairly easy. For staff members and artists, assuming more than one could be involved in a single invoice, it could be more complicated.

hmm, never thought about that for the client's sales report.

At this time, it's only one staff member per invoice.

A client can purchase art from multiple artists and do.

The report gives the ability to group by a date range, a staff member, a client and a artist. I'm not sure if it'll be useed any further than 1)a date range, 2)a date range and an artist.

I think my initial problem of items mysteriously moving to other invoices, or clients moving/gaining invoices they did not have by adding commit record/request in all the important spots, as well as not entering/updating data via a portal. I hope. It's just frustrating that it's doing this some how. I'm having trouble pinning down that it is user error too.

I come from web applications and MS access where i was writing SQL for queries and such, so it's been interesting to figure out how to translate queries to finds and storage and such in fm pro.