 | |
#11
 
| |||
| |||
|
Re: globals initialising -
06-22-2007
, 06:27 PM
|
In article <1182438760.177181.39830 (AT) u2g2000hsc (DOT) googlegroups.com>, thdyoung (AT) googlemail (DOT) com wrote: possibly this question reveals great ignorance, so here goes... are all global field reset to blank on opening up an FMP file ? is there a script which will reset all global fields in a file, at one fell swoop, to no value ? The data in Global fields is saved when the file is closed ... unless you are connecting to a file hosted by another computer / server (in which case only the Global field changes made by the host computer are saved). The only way I know of to wipe the content of all Global fields in one go is to use the Save A Copy As Clone option. That creates a COPY of the file with NO data at all, so you would then have to import the normal record data from the original file, delete / rename the original file, and then rename the new copy to the original file's name. A better way is to have an Opening or Closing script that uses Set Field commands to empty the Global fields. ie. Set Field [g_GlobalField1, ""] Set Field [g_GlobalField2, ""] Set Field [g_GlobalField3, ""] etc. An easier way if there are LOTS of Global fields you want to empty might be to use a separate file / table to store the "global" data as a normal record data (with relationships to let you access the data) and then simply have the Opening / Closing script delete that record. Helpful Harry Hopefully helping harassed humans happily handle handiwork hardships ;o) |
In will add an observation here. A Harry suggests: '... might be to use
a separate file / table to store the "global" data', suggests to me
that people may still be scattering globals throughout various tables.
If so, why?. Globals don't need a relationship to them to access their
value. If you are using a data separation model (user/data file pair)
then all the globals table can be put in that (I use 2: uUser, uAdmin).
Without wishing to get into an architecural merit discussion, this has
some advantages in flexibilty...
creating a set g_Field = "" script is simple, duplicate and reset to the
next field in the list; 2 minutes.
as always, FM8A caveat
regards
Chris
#12
| |||
| |||
|
|
Helpful Harry wrote: In article <1182438760.177181.39... (AT) u2g2000hsc (DOT) googlegroups.com>, thdyo... (AT) googlemail (DOT) com wrote: possibly this question reveals great ignorance, so here goes... are all global field reset to blank on opening up an FMP file ? is there a script which will reset all global fields in a file, at one fell swoop, to no value ? The data in Global fields is saved when the file is closed ... unless you are connecting to a file hosted by another computer / server (in which case only the Global field changes made by the host computer are saved). The only way I know of to wipe the content of all Global fields in one go is to use the Save A Copy As Clone option. That creates a COPY of the file with NO data at all, so you would then have to import the normal record data from the original file, delete / rename the original file, and then rename the new copy to the original file's name. A better way is to have an Opening or Closing script that uses Set Field commands to empty the Global fields. ie. Set Field [g_GlobalField1, ""] Set Field [g_GlobalField2, ""] Set Field [g_GlobalField3, ""] etc. An easier way if there are LOTS of Global fields you want to empty might be to use a separate file / table to store the "global" data as a normal record data (with relationships to let you access the data) and then simply have the Opening / Closing script delete that record. Helpful Harry Hopefully helping harassed humans happily handle handiwork hardships ;o) In will add an observation here. A Harry suggests: '... might be to use a separate file / table to store the "global" data', suggests to me that people may still be scattering globals throughout various tables. If so, why?. Globals don't need a relationship to them to access their value. If you are using a data separation model (user/data file pair) then all the globals table can be put in that (I use 2: uUser, uAdmin). Without wishing to get into an architecural merit discussion, this has some advantages in flexibilty... creating a set g_Field = "" script is simple, duplicate and reset to the next field in the list; 2 minutes. as always, FM8A caveat regards Chris |
understanding the universal nature of them, to clarify, there are
situations when you need them in a specific table. As a match field
for a relationship is what I'm thinking of.
#13
| |||
| |||
|
|
On Jun 22, 5:27 pm, Chris Brown <cbr... (AT) medicine (DOT) adelaide.edu.au wrote: Helpful Harry wrote: In article <1182438760.177181.39... (AT) u2g2000hsc (DOT) googlegroups.com>, thdyo... (AT) googlemail (DOT) com wrote: possibly this question reveals great ignorance, so here goes... are all global field reset to blank on opening up an FMP file ? is there a script which will reset all global fields in a file, at one fell swoop, to no value ? The data in Global fields is saved when the file is closed ... unless you are connecting to a file hosted by another computer / server (in which case only the Global field changes made by the host computer are saved). The only way I know of to wipe the content of all Global fields in one go is to use the Save A Copy As Clone option. That creates a COPY of the file with NO data at all, so you would then have to import the normal record data from the original file, delete / rename the original file, and then rename the new copy to the original file's name. A better way is to have an Opening or Closing script that uses Set Field commands to empty the Global fields. ie. Set Field [g_GlobalField1, ""] Set Field [g_GlobalField2, ""] Set Field [g_GlobalField3, ""] etc. An easier way if there are LOTS of Global fields you want to empty might be to use a separate file / table to store the "global" data as a normal record data (with relationships to let you access the data) and then simply have the Opening / Closing script delete that record. Helpful Harry Hopefully helping harassed humans happily handle handiwork hardships ;o) In will add an observation here. A Harry suggests: '... might be to use a separate file / table to store the "global" data', suggests to me that people may still be scattering globals throughout various tables. If so, why?. Globals don't need a relationship to them to access their value. If you are using a data separation model (user/data file pair) then all the globals table can be put in that (I use 2: uUser, uAdmin). Without wishing to get into an architecural merit discussion, this has some advantages in flexibilty... creating a set g_Field = "" script is simple, duplicate and reset to the next field in the list; 2 minutes. as always, FM8A caveat regards Chris While I'm sure globals are often scattered around tables without understanding the universal nature of them, to clarify, there are situations when you need them in a specific table. As a match field for a relationship is what I'm thinking of. |
Hi Grip,
yes I know the requirement, and used to do the same Now I always create
a hopped rel from tblA/uUser/tblB, parsing the A keys to uUser as well
(uUser being my globals table).
regards
Chris
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.