Delivering an Access app to a client

[nn0410]

I am about to deliver my first Access application to a client and am
trying to do things "right" now, so as to make future maintenance as
painless as possible for the client and myself. Following the initial
delivery and installation, I'll be conducting ongoing
development/maintenance on my premises, and then visiting the client's
office periodically to install updates.

Having never done this before, I'd greatly appreciate a reality check
on this plan:

Initial delivery:
- Split the database and deploy the "_be" part on the network server at
the client's office
- Use the Linked Table Manager to configure the front-end to reference
tables on the server
- Install a copy of the front-end on each user's workstation
- Test

Delivering an update:
- Make a backup copy of the "_be" file
- If the update involves changes to any table, open the "_be" file and
revise its tables accordingly
- Use the Linked Table Manager to configure the new front-end to
reference tables on the server
- Replace each user workstation's copy of the front-end with the new
version
- Test

Thanks

Rick

[Keith Wilby]

<nn****@optonline.net> wrote in message
news:11**********************@t31g2000cwb.googlegr oups.com...

I am about to deliver my first Access application to a client and am
trying to do things "right" now, so as to make future maintenance as
painless as possible for the client and myself. Following the initial
delivery and installation, I'll be conducting ongoing
development/maintenance on my premises, and then visiting the client's
office periodically to install updates.

Having never done this before, I'd greatly appreciate a reality check
on this plan:

Initial delivery:
- Split the database and deploy the "_be" part on the network server at
the client's office
- Use the Linked Table Manager to configure the front-end to reference
tables on the server
- Install a copy of the front-end on each user's workstation
- Test

Delivering an update:
- Make a backup copy of the "_be" file
- If the update involves changes to any table, open the "_be" file and
revise its tables accordingly
- Use the Linked Table Manager to configure the new front-end to
reference tables on the server
- Replace each user workstation's copy of the front-end with the new
version
- Test

Thanks

Rick

You're making a lot of work for yourself IMO ;-)

I would deploy the FE in a read-only public folder and have the users'
shortcut open a batch file which copies the FE from the public folder to a
folder on their local drive and then opens it. You can also deploy batch
files in the public folder to prepare the users' PCs to recieve the FE (ie
create the local folder and copy a shortcut to their profile. It's a system
that I use and it works flawlessly. It means that you need only deploy the
FE once and the users always get the most recent version. Example code
follows:

ECHO OFF
DEL "%userprofile%\MyLocalFolder\*.*" /Q
RD "%userprofile%\MyLocalFolder"
MKDIR "%userprofile%\MyLocalFolder"
DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\\MyPublicFolder\MyShortcut.lnk" "%userprofile%\desktop"

****

ECHO OFF
DEL "%userprofile%\MyLocalFolder\*.*" /Q
XCOPY "X:\MyPublicFolder\MyApp.mdb" "%userprofile%\MyLocalFolder" /I
START "MyApp" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
"%userprofile%\MyLocalFolder\MyApp.mdb"

To modify the BE you need to have exclusive access. I would move the BE to
a development area where there is no danger of a connection being made to
make mods, compact etc, then copy it back.

HTH - Keith.
www.keithwilby.com

[nn0410]

Keith -

Many thanks, I will use your idea when doing the initial installation.
Does everything else in my plan sound OK?

Rick

[Br]

nn****@optonline.net wrote:

I am about to deliver my first Access application to a client and am
trying to do things "right" now, so as to make future maintenance as
painless as possible for the client and myself. Following the initial
delivery and installation, I'll be conducting ongoing
development/maintenance on my premises, and then visiting the client's
office periodically to install updates.

Having never done this before, I'd greatly appreciate a reality check
on this plan:

Initial delivery:
- Split the database and deploy the "_be" part on the network server
at the client's office
- Use the Linked Table Manager to configure the front-end to reference
tables on the server
- Install a copy of the front-end on each user's workstation
- Test

Delivering an update:
- Make a backup copy of the "_be" file
- If the update involves changes to any table, open the "_be" file and
revise its tables accordingly
- Use the Linked Table Manager to configure the new front-end to
reference tables on the server
- Replace each user workstation's copy of the front-end with the new
version
- Test

Thanks

Rick

I usually get the client to send me the BE (ZIPed) if it needs changes (or
you can implement changes by code if you like). If there are changes to the
FE I just send them a new one (packaged). It's not always convenient to go
onsite, esp if they are interstate or if you end up having multiple
installations.

Some clients however insist on "hand holding" and I always go onsite.. but
they have the money to spend too.

regards,

Br@dley

[nn0410]

Br@dley,

This particular client is a nonprofit that I volunteer for at their
office once a week, so on-site maintenance is viable. But thank you
nevertheless! I'll keep your maintenance plan in mind should I take
on work where site visits aren't practical.

Rick

[David W. Fenton]

"Br@dley" <do***********@google.com> wrote in
news:e2**********@news-02.connect.com.au:

I usually get the client to send me the BE (ZIPed) if it needs
changes (or you can implement changes by code if you like). If
there are changes to the FE I just send them a new one (packaged).
It's not always convenient to go onsite, esp if they are
interstate or if you end up having multiple installations.

Some clients however insist on "hand holding" and I always go
onsite.. but they have the money to spend too.

I insist on onsite unless they provide me with a Terminal Server
logon.

I still insist on at least some onsite, if it's at all practical
(obviously, I have not insisted on it with clients who are in
Florida and Washington state).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Br]

David W. Fenton wrote:

"Br@dley" <do***********@google.com> wrote in
news:e2**********@news-02.connect.com.au:

I usually get the client to send me the BE (ZIPed) if it needs
changes (or you can implement changes by code if you like). If
there are changes to the FE I just send them a new one (packaged).
It's not always convenient to go onsite, esp if they are
interstate or if you end up having multiple installations.

Some clients however insist on "hand holding" and I always go
onsite.. but they have the money to spend too.
I insist on onsite unless they provide me with a Terminal Server
logon.

Why waste their money/time needlessly?
I still insist on at least some onsite, if it's at all practical
(obviously, I have not insisted on it with clients who are in
Florida and Washington state).

If it's just maintenance updates both parties have better things to spend
their time/money on.

regards,

Br@dley

[Br]

nn****@optonline.net wrote:

Br@dley,

This particular client is a nonprofit that I volunteer for at their
office once a week, so on-site maintenance is viable. But thank you
nevertheless! I'll keep your maintenance plan in mind should I take
on work where site visits aren't practical.

Rick

I also have built a major app for a non-profit organisation... for which I
do what I described before. In future because the app is going into other
organisations I'm looking at "patching" the BE database via code (it's not
that complex as the changes are usually adding tables/fields).

regards,

Br@dley

[Keith Wilby]

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

I insist on onsite unless they provide me with a Terminal Server
logon.

I still insist on at least some onsite, if it's at all practical
(obviously, I have not insisted on it with clients who are in
Florida and Washington state).

Why?

[David W. Fenton]

"Br@dley" <do***********@google.com> wrote in
news:e2**********@news-02.connect.com.au:

David W. Fenton wrote:

"Br@dley" <do***********@google.com> wrote in
news:e2**********@news-02.connect.com.au:

I usually get the client to send me the BE (ZIPed) if it needs
changes (or you can implement changes by code if you like). If
there are changes to the FE I just send them a new one
(packaged). It's not always convenient to go onsite, esp if they
are interstate or if you end up having multiple installations.

Some clients however insist on "hand holding" and I always go
onsite.. but they have the money to spend too.

I insist on onsite unless they provide me with a Terminal Server
logon.

Why waste their money/time needlessly?

I don't see it as a waste of money. There are things that you learn
onsite that make the project run better.

I still insist on at least some onsite, if it's at all practical
(obviously, I have not insisted on it with clients who are in
Florida and Washington state).

If it's just maintenance updates both parties have better things
to spend their time/money on.

It entirely depends on the specific situation.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tom]

- Use the Linked Table Manager to configure the front-end to reference
tables on the server

Don't count on the Linked Table Manager being installed. I've
frequently found that its not and you either need a means of relinking
in code or find the IT folks onsite with the Office Install disk.

I'll leave it to you to figure out which is the least painful method
for your situation!

Tom

[Jeremy Wallace]

One other thing you can do in the batch file is test whether or not the
client actually needs a new front end. I've got a version of a batch
file that does this on my old website, at www.abcdataworks.com, in the
Developer's section.

Jeremy
--
Jeremy Wallace
Fund for the City of New York
metrix.fcny.org