Global problem

[Mr.Morning]

I created a global field and it will only allow for the one entry. It will not change the data. How do I get it to change the data. It keeps defaulting to the original data imput into the field.

Thanks in advance.

-Morning Man

[Kurt Knippel]

A global field is not really a field in a record. It is a special type of field that exists for the database as a whole. The data in it will be the same as far as all records are concearned, and it exists only for the duration of the current session. The only way to "default" the value of a global field is to be the ONLY user of a database (such as launching the DB locally) in which case the global value will be stored and restored when the DB is next opened.

What is it that you are trying to accomplish?

[jkarol]

I have the same problem. I have one database with around 200 records with an overall "Effective as of" date field that should apply to all of them. I have the Effective Date as a global field displayed on all the records, but I can't change it while sharing it. Seems silly to have to have a separate database just to hold a single date.

In another database I have a different global field for each state. I guess I could put them all in a separate database with each state a different record, but I was hoping to leave them where they are so that a change in one state applies to all records.

Any ideas? This seems to be a not uncommon issue, anyone know if changing global fields in shared databases is allowed in 6.0?

[danjacoby]

CaptKurt --

When you say a global field "exists only for the duration of the current session", are you referring to a multi-user environment? Because I have global fields in a single-user environment which retain their values between sessions.

[kenneth2k1]

As do I

[mborgens]

Absolutely, global fields do not maintain changes in multi-user environments. The field defaults to the info it had when it was placed on the server (very frustrating); but in single-user mode it works without a hitch.

mb

[LiveOak]

There is no problem to be fixed. Globals are unique to the user so they can be used as variables. If your loop counter was changed by other users, life would be pretty difficult. If you need to store values for common use, create normal fields in a "Preferences" file with a single record.

This is unlikely to be "fixed" in any version, it isn't broken!

-bd

[jkarol]

So it isn't broken, it's just designed in such a way that I have to create a separate file for my users to use just to change a single global field that relates to all the records in the original file.

And it isn't broken because it would be bad if users could change a loop counter. Well there's no reason that users couldn't edit global fields in a multi-user environment while still keeping other fields protected. I understand that there are ways to accomplish what I want to accomplish, but just not as elegant a way as I feel there ought to be.

So I guess broken means not working in the way it was designed to work--even if it was designed to work in an inflexible way.

[danjacoby]

It would be nice if the content of global fields were dependent on UserName; that way, they could maintain their values between sessions in a multi-user environment. I suspect, however, that this feature is much harder to program than to desire.

[LiveOak]

All other field data in FM EXCEPT global fields are exactly the type of shared data you want. The fact that there is not a shared variable is kind of splitting hairs, it is easy to implement as I indicated. If globals were shared, it would be MAJOR problem to implement an unshared, local variable.

A shared variable might be nice, but given a choice, I wouldn't replace globals with it. If you start using a preference file in your systems, you will find it useful for a host of purposes.

-bd

[LiveOak]

I think you are correct. At present there is no information stored by user. Server can host up to 250 concurrent "users", but the user information of which you speak could be for an unlimited number of non-concurrent users. Not to mention, that FM doesn't currently have the concept of a user, just a password or group. If you used machine name...well, that would be another whole set of problems. Half of the windows machines at some facilities I've been to seem to have the same FM user's (machine) name.

-bd

[Rigsby]

In a multi user environment, each user should be using a startup file and thus script to log onto the hosted files on a server. This script only needs one record and can contain all the users preferred values. A script at startup can then transfer all these values to global fields in the hosted databases. So what exactly is the problem here? Global fields allow users to have individual variables

[jkarol]

I really don't see how this applies to my situation. I have a file with many records that is used by many users. I want any of these users with permission to be able to change a date field that applies to all records. I don't want it automatically calculated; I want those users to be able to change it to whatever they want whenever they want. That's why I wanted the date to be stored in a global field that user's could change--but I understand now that this is not how filemaker works.

So I don't see how creating a login file would be the answer to my problem (besides being a lot less elegant than the way I was hoping it would work.)

Really I posted to this forum hoping to get some ideas about how to solve my problem not to be lectured on all the unrelated benefits of one way of designing fm databases. I like fm but would like to see added features. I am not the first person to post to this forum thinking that being able to change a global field in a multi-user environment would be beneficial. If there is already a way around this, that doesn't mean that the simple way wouldn't be an improvement.

In short, I am not "blaming my tools", I am asking for help in how to use them to accomplish what I am trying to accomplish. As yet, I have not received an answer.

[Kurt Knippel]

Global Fields are not really fields in the traditional sense. They are implemented as fields for the sake of interface, but they are really VARIABLES. Each user has thier own set in a multi-user environment, and they are not persistant and will reset to the defaults each time the file is opened.

If you want a Date to be referenced by all records, then what you really need is some type of "Preferences" file. This is typically a single record file which contains a bunch of fields that are real fields (not globals) and are used by the solution as a whole.

What I do is have this Prefs.fp5 file with whatever fields I need as well as a Constant field (calculation = 1) and I also have this Constant field in all of my other files. All those other files have a relationship to Prefs.fp5 via the Constant field. Thus all records in all files have access to the data stored in the Prefs.fp5 file.