Editing auto-enter data???

[BShepTPC]

I want to be able to edit the data that is aut-entered into a related field without editing the matching relationship, is this possible? Right now, when i edit the field, it also edits the related field, I don't want to do that. Can and how can this be avoided? Thanks!

[Søren Dyhr]

This isn't particular clear?

--sd

[BShepTPC]

ok sorry, I'll try to be more specific...Right now I have a client contact database and an invoice program related to each other. I have a auto enter lookup for the company and address. After the lookup occurs, I would like to be able to edit the data in the invoice field and not have it interfere with the data in the client contact database, any better?

[T-Square]

Assuming that the fields you are editing do not form part of your relationship, and assuming (as you imply) that these fields are set up as lookup fields, you should have no problem simply editing the content of the looked up fields.

What I suspect is happening is that you have placed the original field (Contacts::Address) on your Invoice layout, when you really want Invoices::Address there.

David

[BShepTPC]

I can edit the invoice field without problem, but when I type in the invoice field, it shows up on the related contacts field and I don't want that to happen. Im not sure if Im being clear enough or not. and yes, the layouts are correctly defined

Edited February 20, 2006 by Guest

[BShepTPC]

anyone? please?

[LaRetta]

"I type in the invoice field, it shows up on the related contacts field and I don't want that to happen"

Nope, it shouldn't. You say your 'layouts' are fine and they may be. But you nonetheless have something wonky, as David pointed out. Either you have a lookup auto-enter on your CONTACTS field, you have a calculaton of your Invoice field in your Contacts table, OR ... you've placed your Contacts fields directly on your Invoice layout. :wink2:

[Søren Dyhr]

m not sure if Im being clear enough or not. and yes, the layouts are correctly defined

No not quite, a lookup is an autoenter value in the Invoice table USING the relation made by entering the clientID in the linking field for the relation. What it seems to be done, is that you have pulled a field from the related database and deployed it in the invoice layout - thats not a lookup!

--sd

[BShepTPC]

"What it seems to be done, is that you have pulled a field from the related database and deployed it in the invoice layout - thats not a lookup!"

I think this is my mistake then, but I will explain step by step what is happening here.

In the "invoice" layout, I go to define database, then to relationships. Then I relate "client ID" in the invoice layout, to "client ID" in the contact database. After this is done, I go to "fields" in define database. I then go to "address", click on options, in storage I index "all" then I go to auto-enter and specify a Looked up value by then going to "lookup from related table" and click on "contact database", then the fields from that database show, and I choose "address", and that is it. Any ideas?

Go easy on me please, im still a Newbie, thanks!

[LaRetta]

Have you verified that:

1) The address field appearing on your Invoices layout is based up Invoices and not Contacts? Right-click on the field to see its field spec.

2) You have added the Lookup to your address field in Invoices (in Define Fields) and NOT the reverse?

What you've described sounds right and should work. If 1 and 2 are correct then we would probably need to see your file. :wink2:

[BShepTPC]

ok, i got it thank you for all your help! The invoice field was specified in the contacts field, sorry!

One other question though, I have 6 repetitions in the contacts field for address info, and now when the lookup occurs to the invoice field, it only shows the first repetition, any chance I could get some help on how to have all 6 show up in the invoice field?

[Digital Life]

In layout mode click on the field that has the repetitions and go to the "Format" menu and pick "Field format". In the window that opens you'll see near the bottom "Show repetitions". There you can put in 1, some or all of the repetitions and show them vertically or horizontally.

[BShepTPC]

I already have it set to "Show Repetitions" 1 through 6". It seems to only be looking up one repetition instead of all 6. When I had it the other way (posts above), all 6 from the contacts showed up in the invoice field.....

[Søren Dyhr]

all 6 from the contacts showed up in the invoice field.

What is this? Six different contacts looked up for one single invoice, strange business model indeed! Timeshare arrangement or extortion racket?

--sd

[BShepTPC]

the 6 repetitions are name, street, city, state, zip, and phone #, how is that strange??

[Søren Dyhr]

Something called 1NF requires one fact per field, so mixing values with different meaning isn't particular database'ish. What you need is to make each field containing just address or name or zip - what you're after is to grap the entire adress when entering the client's ID into field where you can modify if needed. Not all values are likely to need such treatment, but you could if you wish to, but another database'ish issue is to prevent storing redundnant data.

Where it usually goes wrong is the fling all novice developers get with repeating fields, intuitively do they, on the surface have all the nice features a lovesick could wish for ...but they're the first genuine pitfall your reasoning will encounter with filemaker.

A repeating lookup needs a repeating keyfield to work properly, so mixing adresses with names will prove pure luck to make sense ...I know it's not what you're intending to do, you would store names with adresses as repeating fields as well.

This means that that measures should be made to ensure a keyvalue is published into all repetions in the keyfield, this means that the keyfield should be a calcfield or an autoenter containing something in the vicinity of:

GetAsNumber ( Extend ( SingleValue ) & "" )

...provided the keyfield is a number. But perhaps you should join the club of us mere mortals that recognizes that the research of Boyce & Codd might prove a point or two in normalization of data structures.

http://www.datamodel.org/NormalizationRules.html

...I mean when asking in the first place isn't there a notion of not knowing all or a feeling of being cought by hasty conclusions? Or is it - the world is evil to pure geniuses?

--sd

[Digital Life]

BShepTPC, Did you get the answer that you need here?

[Søren Dyhr]

Alright lets boil it down to:

A repeating lookup needs a repeating keyfield to work properly

...provided the looked up field is repeating as well.

--sd

[BShepTPC]

yes the related field is a repeating field as well. Im not sure how to go about having a keyfield, Im not familiar with the term, so Digital Life, we are getting somewhere, but I havent solved it yet!

[Digital Life]

Let's say you have 2 tables/files: table one and table two

A key field would be a field in table/file one that is used in a relationship to point to another field in another table/file, say table/file two. If the key field in table/file one contains a match in content to the content of the other field in table/file two then the two records are related and you can use that relationship to pull information via a lookup into table/file one from table/file two.

There are all kinds of variations on this. eg) in recent versions of Filemaker the relationship does not have to be strictly equal. But let's not get hung up on that right now.

You must have created a relationship in your project because you have said in your posts that you are doing a lookup. So there must be two fields in two tables or files that you are relating to do the lookup. Those fields are commonly called key fields and are often simply a unique number automatically entered for each record in a table/file.