RE: Compare Front Ends
- From: Jack Leach <dymondjack at hot mail dot com>
- Date: Wed, 11 Nov 2009 17:10:01 -0800
Do you have any particular worry about deploying a brand new FE rather than
importing the updated objects? Personally I prefer this approach just
because you're not "patching" together an app. It seems as though importing
objects might be dangerous and might easily lead to some corruption issues if
not handled very carefully.
That said, Tony (among a few others, but I use his) has an AutoFE Updater
program that works excellent. Store the active version of the FE (and any
files that go with it) on the server, and his startup app will copy over any
nonexistent or more recently updated files to the users FE location. This
happens every time they start the app and works seamlessly. Not to mention
that deploying the app is easy. Just copy the new FE over the old one in the
server folder and you're done.
http://www.autofeupdater.com/
--
Jack Leach
www.tristatemachine.com
"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
"JimS" wrote:
So, when I do development (largely maintenance) on my front end, I make a.
sandbox, do the work in the sandbox, test it, then transfer the objects I
edited back to the original FEdb. I've been know to make mistakes keeping
track of which objects to move.
Has anyone (other than Luke and FMS) created a "compare objects in a
database" program to identify, mark, and transfer revised objects (queries,
forms, reports, classes, modules....)?
I know VSS is available, but for me it would be dificult because my target
and development environment are on my client's (closed) system. It also
costsl money...
A2007..
Jim
--
Jim
- References:
- Compare Front Ends
- From: JimS
- Compare Front Ends
- Prev by Date: Repeat Field Value
- Next by Date: Re: Excel won't go away
- Previous by thread: Compare Front Ends
- Index(es):
Relevant Pages
|