Re: Question about "updating" an .MDE remotely

From: Rick Brandt (rickbrandt2_at_hotmail.com)
Date: 10/29/04


Date: Fri, 29 Oct 2004 09:55:32 -0500


"Joey" <Joey@discussions.microsoft.com> wrote in message
news:3F357852-841D-4224-A525-69C6352508E8@microsoft.com...
> I have a question that I'm hoping some of you will have had some
experience
> with so will hopefully be willing to share some insight with me.
> I have an application .MDE that is on a remote machine (out of state).
This
> app has been running over a year with no problems. Now, I have made some
> necessary changes to a form and want to replace the old form with the new
> form in the remote .MDE. (Traveling to each remote location is not an
> option.)
> Have you guys ever done this type of thing by creating some type of
"service
> patch" that a user can run and have it update changes like this? Is this
> possible? How do you handle updating existing REMOTE apps with the
> inevitable changes that occur over time???
> All input is greatly appreciated!

You can't do this with an MDE although it would be possible in an MDB.

The "best practice" is to always split your app into a front end file and a
back end file (tables only). Then front end updates (the most common) are
a simple matter of replacing the entire file. Data is not affected because
it's in another file.

Of course sometime the updates involve changes to tables as well but since
the back end is tables only you can still make modify it. For small
changes I would typically have run-once code in a new front end that would
programmatically implement the changes to the back end file when it's used
for the first time. For extensive back end changes it might be simpler to
replace it with a new one and then have an automated routine to pull in all
of the data from the old data file.

-- 
I don't check the Email account attached
to this message.     Send instead to...
RBrandt    at       Hunter      dot      com


Relevant Pages

  • Re: Extremely slow debugging performance in VS2003 with interop
    ... in the debugger now executes CreateInstance in 12 secs instead of 45. ... However, the second time I run the app, I'm back ... to 45 seconds every first time I run the app in the debugger. ... Here is the 12 second output: ...
    (microsoft.public.vsnet.debugging)
  • Re: Extremely slow debugging performance in VS2003 with interop
    ... > rename the file to symsrv.dll.hide, start VS and the initial run of the app ... > in the debugger now executes CreateInstance in 12 secs instead of 45. ... > to 45 seconds every first time I run the app in the debugger. ... > Here is the 12 second output: ...
    (microsoft.public.vsnet.debugging)
  • Re: Windows XP auto updates stinks!!
    ... just use one exploit whereas you have to test all patches. ... you needn't install them. ... so I ignore any updates to it. ... you install an incompatible app ...
    (microsoft.public.windowsxp.general)
  • Re: WindowsXP memory error
    ... An app not shutting down correctly may be a problem with that particular ... Check for any App updates ... > I am have a problem with my Windows XP. ... > else or access the internet. ...
    (microsoft.public.windowsxp.hardware)
  • Re: SqlceException.SqlceException
    ... First of all, i found the cause of the exception and corrected it, it was ... > same challenge in terms of deploying the initial SQL CE database. ... > db along with your app. ... it is the first time i am doing mobile applications and the first ...
    (microsoft.public.sqlserver.ce)