The whole idea of globals.
Yes, "The whole idea of globals".
The question is "Why can't the global fields be imported?
Does the source table contain a record, or do you have the global values only with zero records in the table? If th latter, try creating a record and running your import again.
No, the question is why you are trying to do this in the first place.
Use a single record preference table with real fields in it.
THEN set global fields - if necessary, by startup script.
Why am I doing this in the first place?
In brief, my app has fields for Company Name, Address, City St Zip etc...
Sometimes users download an update of the application.
They need to import their data (including Company Name, Address, City, St, ZIP etc from the source (Prior version) into the new version.
I checked the Source and it has values in the global fields...
Again: this is not a place where you should be using global fields.
Why do this in the first place?
Seems like the question is "Why can't I do this"? Specifically, why does FM work to prevent what seems like a valid import. (See screen captures above).
Yes, I agree that I could do the same thing using non-global fields. But, now I am wondering "Why doesn't this work"?
The key point is that you can't, and the behavior you're getting is expected.
Global fields do not do what you imagine they do.
Use standard fields.
Excellent question KEYWORDS.
I opened the Source Global layout and there were no records. I added a record and ba boom. The import works as expected.
My 'take away' from this is that I will have to remember that 'factoid' when I create my import scripts.
Thank you very much.
I would listen to what Bruce is trying to tell you...
I highly advise that you take the time to fully understand the function and purpose of Global Fields before you go any further. Global fields are absolutely NOT, a place to "store" data.
Just my 2 cents worth.
"Not a place to 'store' data.???"
Interesting admonition. Now you've got me interested. Why aren't global fields a place to store data? Isn't storing data what databases are all about? Does the fact that the value in a global field is represented across all records somehow make it '... NOT a place to store data'. If you don't store 'data' in global fields, what are they good for?
Please enlighten me.
There are several very important uses for Global Fields... But, they only will store data under limited conditions.
They are "Session Specific" this means that if more than one user is accessing the same database they can each enter there own values, without effecting the other user. Think of them more as temporary data holders. Good for holding filter values that effect relationships and portal filtering. They are "absolutely essential" for Multi-user development.
Often users get confused, because... when they have data in a Global Field and they re-open a file it is still there... That is only because FM will hold the data that was last stored in single user mode when it opens with FMP,... but the behavior is different in FileMaker Server. The very purpose of Globals is NOT to store data.
I personally believe it is a good practice to clear out all globals on logout, and reset them upon login.
There is no way I could convey the complete use and understanding of Global Fields in a thread like this, but I will tell you they are EXTREMELY important... and "Storing" data is not the only thing a Database is for.
I think if you start working in a Multi-user environment you will quickly discover why.
Thank you for the explanation. It fills some gaps in my understanding.
I neglected to mention that my 'little' app is single user. (Checkbook with Budget)
You can use a global field:
for fields that rarely need to be updated. For example, use global storage to put your company address on several layouts. You can quickly update the value in a field with global storage without having to update each layout.
This is precisely my application for global fields. Since I am in 'single user' mode, don't you think I am safe to use them this way?