Global Field With Value List Trouble When Online

[stealth162]

I have defined a global field that is set up for 10 repetitions. On my layout I have 10 fields which each respectively refer to this global field. The entry into these fields is done via a common value list. I basically use this to keep track of different versions. ie/ field 1 = version a14, field 2 = version a15, field 3 = version a14.

This setup has been working fine so far until the other day when I put it online to share with other users. What happens is that I set my versions for each of the respective fields based on my defined value list and all looks good. However when I close the database and relogin to it all the fields that I have set versions for show up blank. If I clik on the field to bring up the value list the values are still there but, they are no longer set for each of these ten fields.

Strangely enough I have found that if I switch to another layout in this database and perform a find of any kind and then go back to this original layout with the global field the values reappear in the respective fields.

Any thoughts?

[transpower]

Don't use a global field for this; global fields should store just temporary values. Use another table for your so-called global fields and store the values there in one record.

[-Queue-]

Global fields are local to a user's session. They do not retain changes unless the file is single-user or multi-user with only one current user when the file is closed. So they will never retain changed values for guests, whether using Server or a dedicated host.

You would be better off using a one-record table, with normal text, number, etc. fields, that is related to other tables via a Cartesian (X operator) join for a preferences table.

[stealth162]

Thanks for your replies Transpower and Queue. I'm a bit stuck with understanding how to achieve the same results as I had. I believe you both helped me initially set this up.

Refer to this thread and let me know what your thoughts are then.

http://www.fmforums.com/threads/showflat...&PHPSESSID=

[-Queue-]

That was for a global calculation used in a single table, which will naturally update when a referenced field is changed on the current record and can be initialized when opening a file by setting one of its dependent values to itself. If you're not using a calculation and are putting it in its own table, you can still initialize the values on open, but it is much easier to use a 'universal' as we have described, instead of a global.

[stealth162]

I think I get the gist of what you're saying. I have never dealt with tables and I'm not sure how to change what I currently have (global field) to a table. I appreciate any instruction you might be able to provide.

I am simply the padawan learner.

[-Queue-]

Okay. Create a new table, called Prefs, containing a number or text field, depending on your needs. Populate this field as necessary. Then create a relationship from one of these fields to the serial field in each table that requires its data. Use the X operator for each relationship. This will relate the one record in Prefs to every record in the necessary tables. Then, change your calculations to reference the related field instead of the global.

Now whenever you change the Prefs' field, any dependent calculations will update.

[stealth162]

I'm not sure if that solution will work for my problem. I'm also having this strange issue. I have on my "main menu" a field where you can enter a "show name" and a "editor name" (this is a film post database). That info is then simply displayed in the header on all the rest of the layouts. Strange is that they are just text fields (not global) and when I move between records in the database the info in those field appears and disappears.

I think these two problems are somehow related. Any thoughts? I'd be willing to send a copy of the file if you think you'd have time to take a look.

[-Queue-]

You can't use one record's data for another record, unless you have a relationship defined between them.

You need a Cartesian relationship (using the X operator) between any table that needs the 'name' info and the main menu. This way, all records will relate to the single record in main menu. Put this related field in your header.

It seems to me that you may have more than one record in your main menu table's layout, which will not work.

[stealth162]

I have no tables in my main menu. And the entry of info isn't even done on a record. It is done via a layout. And then that info is displayed as a header globably, not specifically for one record.

I'm not sure if I really get it. Just a newbie as it says. If you're willing to check it out I wouldn't mind emailing it to you. I'd rather not post it.

[-Queue-]

Layouts are merely visual record displays of the desired field data. If you enter something, it's into a field in a record, regardless of the layout, but dependent on which table occurrence the layout is based in Layouts -> Layout Setup (in Layout Mode).

A main menu or preferences table should be a table itself, containing only one record, not merely a layout from another table that contains multiple records. This is, of course, unless you are using globals, which are available to all records in a table and to all other tables which have at least one table occurrence in Define Database -> Relationships.

It makes sense that your header info doesn't display consistently, because you're only entering the 'name' data into one record and not using globals. So it is local to that record and all the other records have their own 'name' fields, which are empty.

I will take a look at your file. I've pmed you with my email address. But you would do well to purchase a FileMaker book, which will give you a better understanding of files, tables, layouts, fields, records, and relationships.

[stealth162]

Hi Q,

Have you had a chance to take a look?

[-Queue-]

Yes. Is there only going to be one project in the file? It appears that way in the MainMenu layout header. If there will be more than one (which would be my assumption), then you wouldn't want to have project specific data showing in the MainMenu. Although, you could select a project from the MainMenu and go to its related project record.

You need to determine what constitutes an entity and whether you need additional tables for these entities. Obviously, you need a Projects table and a MainMenu (this may not be true, depending on what data you want to display in the MainMenu) table, but should Composer, Supervisor, and Cue information be in their own tables also? Do you have any one-to-many relationships or is everything one-to-one? Answering these questions and setting up your file appropriately will make it much easier to figure out where to go from here.

[stealth162]

Thanks for taking a look. Initially I wanted to setup the database to accomodate many different projects that way you could quickly reference a older project and it's related records. However, I wasn't sure if this was possible so I went with the latter. It would be great to set it up to accomodate many projects, if not I would settle for the way it is now and simply archiving the files and switching between them for reference. You are correct in saying that if it was able to handle multiple projects I wouldn't want the specific data such as project stage, composer, supervisor and version to be tied to a main menu but, rather tied to a group of records. All the relationships as of now are simply one-to-one.

I'm guess that this fix is much more involved than I initially thought. What are your thoughts as far as setting up the database to handle multiple projects? Is it better to leave it as is? How would you procede? I appreciate the time you are taking to help me with this. Thank you.

[-Queue-]

Bump.

I don't have time to help you redesign your file right now, but perhaps someone else does.