export import

Hello,

Is there a systematic way to export scripts and/or layouts from one file to
another other than copy and paste?

thanks
--
POST BY: lark with PHP News Reader

Re: export import

In article , lark
wrote:

> Hello,
>
> Is there a systematic way to export scripts and/or layouts from one file to
> another other than copy and paste?
>
> thanks

I don't know if there's another way in newer versions of FileMaker, but
there is always File -> Save a Copy as, and then use the Clone (No
Records) option. You'll get a copy of the entire file from which you
can delete the stuff not wanted.

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

Re: export import

In article ,
lark wrote:

> Hello,
>
> Is there a systematic way to export scripts and/or layouts from one file to
> another other than copy and paste?
>
> thanks
> --
> POST BY: lark with PHP News Reader

In FM Advanced/Developer before 9, there is a an option in Scriptmaker
to import scripts from another file. Don't remember if the same option
exists in FM Pro.

In FM 9 Advanced (and perhaps in FMP9 as well) there is the ability to
copy and paste whole scripts or groups of scripts in a single operation,
as well as copy and paste individual script steps and groups of script
steps. You can have multiple windows of Script Manager and individual
script editors from different files open at the same time. It is very
powerful and versatile. Could also get confusing if you don't pay
attention to which window you are looking at. The various windows of
script editor and script manager are named to help you recognize which
is which.

--
For email, change to
Bill Collins

Re: export import

== Quote from Helpful Harry (helpful_harry@nom.de.plume.com)'s article
> In article , lark
> wrote:
> > Hello,
> >
> > Is there a systematic way to export scripts and/or layouts from one file to
> > another other than copy and paste?
> >
> > thanks
> I don't know if there's another way in newer versions of FileMaker, but
> there is always File -> Save a Copy as, and then use the Clone (No
> Records) option. You'll get a copy of the entire file from which you
> can delete the stuff not wanted.
> Helpful Harry
> Hopefully helping harassed humans happily handle handiwork hardships ;o)

insightful; however, not helpful! because i have two production files that i am
trying to keep consistent with my development file. everything i work on is in
8(the two prod files are served from two fm server machines) and I develop on 8
advanced.

clone option is available when i do a save a copy as; however, i don't know how
that would help me to keep the two production files in sync with my development
file if i can't export and import scripts and/or layouts.


--
POST BY: lark with PHP News Reader

Re: export import

In article , lark
wrote:

> == Quote from Helpful Harry (helpful_harry@nom.de.plume.com)'s article
> > In article , lark
> > wrote:
> > > Hello,
> > >
> > > Is there a systematic way to export scripts and/or layouts from one file
> > > to
> > > another other than copy and paste?
> > >
> > > thanks
> > I don't know if there's another way in newer versions of FileMaker, but
> > there is always File -> Save a Copy as, and then use the Clone (No
> > Records) option. You'll get a copy of the entire file from which you
> > can delete the stuff not wanted.
> > Helpful Harry
> > Hopefully helping harassed humans happily handle handiwork hardships ;o)
>
> insightful; however, not helpful! because i have two production files that i
> am trying to keep consistent with my development file. everything i work on
> is in 8(the two prod files are served from two fm server machines) and I
> develop on 8 advanced.
>
> clone option is available when i do a save a copy as; however, i don't know
> how that would help me to keep the two production files in sync with my
> development file if i can't export and import scripts and/or layouts.

The normal way of developing is to work on an empty / clean file that
has never crashed (keeping a backup before making major changes helps
here). Obviously you may need test data.

Once you're happy the development file is working properly you:

- Show all the records in the working file (ie. the one the
users are entering data into)

- Rename the working file to "XYZ (OLD).fm9

- Put a copy of the new file onto the server and import all
the records from the old file.

There shouldn't be a need to import layouts, scripts etc. since they
are already in the new file.

The bonus here is that you're always replacing the working file with a
clean development file, and so any corruption that may be happening
from day-to-day use is thrown away.

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

Re: export import

== Quote from Helpful Harry (helpful_harry@nom.de.plume.com)'s article
> In article , lark
> wrote:
> > == Quote from Helpful Harry (helpful_harry@nom.de.plume.com)'s article
> > > In article , lark
> > > wrote:
> > > > Hello,
> > > >
> > > > Is there a systematic way to export scripts and/or layouts from one file
> > > > to
> > > > another other than copy and paste?
> > > >
> > > > thanks
> > > I don't know if there's another way in newer versions of FileMaker, but
> > > there is always File -> Save a Copy as, and then use the Clone (No
> > > Records) option. You'll get a copy of the entire file from which you
> > > can delete the stuff not wanted.
> > > Helpful Harry
> > > Hopefully helping harassed humans happily handle handiwork hardships ;o)
> >
> > insightful; however, not helpful! because i have two production files that i
> > am trying to keep consistent with my development file. everything i work on
> > is in 8(the two prod files are served from two fm server machines) and I
> > develop on 8 advanced.
> >
> > clone option is available when i do a save a copy as; however, i don't know
> > how that would help me to keep the two production files in sync with my
> > development file if i can't export and import scripts and/or layouts.
> The normal way of developing is to work on an empty / clean file that
> has never crashed (keeping a backup before making major changes helps
> here). Obviously you may need test data.
> Once you're happy the development file is working properly you:
> - Show all the records in the working file (ie. the one the
> users are entering data into)
> - Rename the working file to "XYZ (OLD).fm9
> - Put a copy of the new file onto the server and import all
> the records from the old file.
> There shouldn't be a need to import layouts, scripts etc. since they
> are already in the new file.
> The bonus here is that you're always replacing the working file with a
> clean development file, and so any corruption that may be happening
> from day-to-day use is thrown away.
> Helpful Harry
> Hopefully helping harassed humans happily handle handiwork hardships ;o)



that's great. i think i will start doing it this way but another issue that has
come up, is that of account names. over time, the account names in one file has
become different than account names in the second file and my development file has
a different set of account names in it. if i follow the development model
explained above, won't i lose all the account name/password information and end up
with what is on my development file?

--
POST BY: lark with PHP News Reader

Re: export import

In article , lark
wrote:

> that's great. i think i will start doing it this way but another issue that
> has come up, is that of account names. over time, the account names in one
> file has become different than account names in the second file and my
> development file has a different set of account names in it. if i follow the
> development model explained above, won't i lose all the account name/password
> information and end up with what is on my development file?

Usually as the developer you would have all that information (user
names, passwords, value lists, etc.) and be adjusting it yourself in
your developer files anyway.

BUT,
the exception comes when you're letting users do things like edit value
lists themselves. In these cases, it's often better to side-step
FileMaker's in-built abilities and create your own system by storing
this data as normal records in a separate table. That way you can
reimport them along with all the normal data in the other tables.

As the developer, you should of course have full access to the files
anyway and can therefore simply copy / paste things like customised
value lists over separately. (Although obviously this won't be possible
in a remote roll-out situation, eg. downloadable freeware / shareware
solutions.)


There is another way to the rename / import method I described before.
"Data separation" is a method some people prefer - you have one file
for your data and another for your user interface. The problem I have
with this method is that changes to the database often require altering
fields, scripts and layouts, so you end up changing both files anyway.
But if you're only playing with report formats, for example, then this
might be a help.


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