We all know that Filemaker keeps data and code in the same files. The
question is how can I update the layouts and the code in a solution without
changing the data.

I have a client who is running his business with one of my filemaker
solutions. I want to change layout and code at home and just upgrade the
solution at my clients place without affecting his data.

Yes, of course you can, we all do that, when we are at the client
premisses - in order to be sure one has the latest data - there.
But you really have to document every bit and pieces of your changes made at
home to be sure to make the exact same changes in the copy that your client
has in hands.
If you can't remember all what you've done, you then have to make a clone -
with zero record - of your modified file, say 'YrFile clone.fp7' (I call
this 'structure' to differentiate it from actualized data and records that
only the client has at a given time), then go with it at the client
premisses, ask him to stop running his file, then open his file, make sure
that 'All records are shown' (if not you would import only the 'Found'
records..), and import all records in every table of the Client file. You
may have to verify the 'key' (often called 'ID') which identifies each
record, and if automatically filled up by FMP, check that the field next
number is the last plus one : one easy way to do that is in the original
file to sort (all) the records by this key (ascending order) then go to the
last, which gives you the last utilized ID, note it, and make sure that
after import and 'show all records' and after sort by ID the last one is the
one you noted, and also, that the field definition of 'ID' in the clone has
got for the next number the number you noted plus one. Then, you rename the
original file in adding 'old' to it, and you rename your clone by eliminate
the word 'clone' plus the space from it.
You may well also come to the client's with the old data in the new
structure, and run it on a separate machine with the client to explain your
changes and thus make him validate them. It's often a good move to do that
as often client will claim that it's your changes that made his file all a
sudden not work properly...
Routine work.
Remi-Noel


"Hatzigiannakis Nikos" <ypai (AT) aigaio (DOT) gr> a écrit dans le message de news:
ennn4h$ukc$1 (AT) mouse (DOT) otenet.gr...

In article <459f7901$0$288$426a74cc (AT) news (DOT) free.fr>, "Remi-Noel Menegaux"
<rnmenegaux_AT_free.fr> wrote:


You have to be a little careful with the Clone option. Although it does
save a copy of the file with no records, it also saves it with no
Global field data either ... at least it does in older versions of
FileMaker, hopefully they've fixed it in newer versions. This can be
annoying when you realise that, for example, your custom graphics for
dynamic buttons are not in the new file. (

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

The behavior you describe only works in single-user solutions.

Global variables are empty when a guest of a hosted system logs in... so
it's not good to keep them there anyway. Best practice is instead to have a
table/record for the interface graphics and initialize your global variables
from that on startup.

"Helpful Harry" <helpful_harry (AT) nom (DOT) de.plume.com> wrote

In article <_4SdndR6aZE6vj3YnZ2dnUVZ_v6tnZ2d (AT) comcast (DOT) com>, "Bill
Marriott" <wjm (AT) wjm (DOT) org> wrote:
I very rarely have to deal with multi-user systems, but from what I
understood the Global fields are not empty. I thought that when the
user logs in they are given a copy of the Global field's data from the
host, and after that any changes are really local to each user (which
of course is irrelevant in the above case since the dynamic button
graphic images are simply the source images for each state of the
button).


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Harry,

Oh, sorry you're right.

I spend too much time working on a system more-or-less permanently hosted on
FileMaker Server Advanced. Therefore, I'm always a client. Even if I'm
defining fields, etc., as an administrator, the globals are not saved at the
end of a session, and there is no method for a client of a multi-user system
to write those permanently to the file, unless you open it as the host,
locally.

I just got into the habit of storing the data in a "real" field first, THEN
copying it over.

Just to add my 2cts, I'd say that's one of the reasons for having a
'Parameters' table with one record only where you can store as regular
fields any 'global' value you want to keep for all users.
Remi-Noel

"Bill Marriott" <wjm (AT) wjm (DOT) org> a écrit dans le message de news:
X5CdnWng5PKZpD3YnZ2dnUVZ_o-knZ2d (AT) comcast (DOT) com...

On 2007-01-06 09:37:39 +0100, "Hatzigiannakis Nikos" <ypai (AT) aigaio (DOT) gr> said:

You just have to split the user interface from the data, and this is
not so difficult.
Actually you can make two copys of the solution. Then name the one
file solution_data.fp7 and the other file solution_userinterface.fp7
Now delete all Tables in the userinterface file. Then delete all the
table occurences. Then recrete the Table occurences with reference to
the data file. If you follow the right procedure you even can reuse the
layouts. It is important to name the TO exactly the same in the user
interface file.

I have made my solution from ground up with two datafiles, and now I
really find it easy to work on the database user interface and replace
the one file while all the other data is safely stored in the datafile.
I can even have two versions of the user interface at the same time
working on the same data file.

You have to use filemaker 8 or newer (maybe 7 is ok, I dont know exactly)
Nicolay

In article <45a0a75c$0$292$426a74cc (AT) news (DOT) free.fr>, "Remi-Noel Menegaux"
<rnmenegaux_AT_free.fr> wrote:

For "Global" values that need to be saved by users, then yes you do
need a "parameters" / "variables" Table that uses normal fields and
records ... at least you do in a multi-user environment.

I was talking about Global fields that are used to store static
defaults, the images for the various states of dynamic buttons, etc.
These things aren't changed by the user, so Globals are perfectly OK to
use.

But, the point was that saving a file as a Clone (no records) also
empties the Global fields as well as all the records. So if you're
using Global fields to store anything at all they will become empty in
the cloned file.

You can then either re-create that Global data or instead:

- make a backup of the file
- open the file
- Find/ Show All Records and then Delete them all
- Save As the file to a Compressed Copy

This way you keep all the Global data intact.









Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Hatzigiannakis Nikos wrote:

If you are using a data separation model, then this is relatively simple
no?


Regards

Chris

University of Adelaide