changing info in one field to change all related fields

[sailormoonstwin]

So, I'm kind of a beginner at this. I might not make sense so just ask for clarification.

 

I have an author, author ID, and author initials. They belong in one table (AuthorDetails) but I have them looked up in other tables. The main layout I'm using draws info from the table ArticleDetails and author initials and author ID are looked up. The author that I'm using for the layout comes from CopyDetails. This means that it is also looked up. Should I be working with the actual values instead of the looked up values? Is that where it's having problems. I mean, all the tables have relationships to each other through the author ID.

 

I have value lists for both the author and the author initials. How do I get it to change the author ID and initials to the correct ones when I choose a different author from the value list? Do I have to make a script that does all the comparisons? I'm trying to avoid this because that means having to input any new persons into the script.

 

I'm thinking that there might be a way to make a dynamic script through associating the value lists to each other. Is there a way to make comparisons to a value list? I know I can use ValueListItems() to get an argument with all of the authors and author initials but how do I do a while loop where I continue to compare against the value list until I find the right one? Also, is there a way to truncate words or take the first letter from the author's name to get the initials and then make the comparison?

 

I know it's a lot of questions but I'm having so much trouble with Filemaker since I'm used to programming and this offers limited functions and ways to implement them.

 

Any help appreciated!

 

~Samantha

[Weetbicks]

Are you able to supply an example file? It sounds like you should be using auto-enter calculation option on the fields to place the values into them after choosing an author from the value list.

 

If you want to choose an author, and then be able to update their details from whatever screen you are on - and have these details update across all other records, then you should probably be directly editing the author record...

 

Its pretty hard to explain what I mean, especially without seeing some real example. You definitely did a really good attempt at trying to explain it, but it is still a bit unclear as to exactly the behaviour you are wanting on the various screens, an example file would clear this up.

[sailormoonstwin]

Sorry it took me so long to respond. Thank you for replying.

 

I attached my file but I don't think it's entirely populated. Then again that's how the actual data is too; some of it is missing.

[sailormoonstwin]

oops, here's the link.

 

https://netfiles.uiuc.edu/sdchan/files/Article%20Most%20Recent.fp7

[sailormoonstwin]

I'm usually working from either the Story Details layout or the Publication Status layout. Did I set up the databases incorrectly or are there too many? I'm beginning to think the relationships aren't working.

[sujat]

The link is asking for password.

[sailormoonstwin]

sorry, please try again.

[sujat]

The Article Details Table and Author ID Table should be related by Author ID.

 

Uncheck Allow creation of records in this table via this relationship in the Author Table.

 

Delete all duplicate records in the Author Table.

[Ender]

I'm usually working from either the Story Details layout or the Publication Status layout. Did I set up the databases incorrectly or are there too many? I'm beginning to think the relationships aren't working.

I think your structure could be improved.

 

In general, one-to-one relationships should be eliminated, and the tables combined. There are few cases where a one-to-one really makes sense.

 

To streamline your structure I'd recommend three tables, in this configuration:

 

Issue -- Author

 

 

All those other tables would be combined into the Article table.

 

Or, you might actually want to remember more than one piece of artwork or more than one video for an article. If this is the case, then the separate tables do make sense, but only if you remove the Unique validation on the Article ID foreign keys and use a portal to show multiple Artwork, Videos, or whatever on the Article screen.