The Next Step

Karen,

As previous replies have said, you can update the Front-End file
easily by sending the client a new version. However, if you will need
to make changes to the Back-End file you need a different method.
Assuming that you cannot visit each client to make the necessary
changes you need to add some code to the Front-End which will make the
relevant changes to the Back-End files automatically.

There is code at this site :-
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE%20Update%20Utilit y.mdb'
which will do that for you. Just import the form, table and code
module into your database, add one line of code to your 'start up'
form and you are done. To add a new table or field to the Back-End you
just call up the BE Update form, enter the details of the table,
field, relationship, etc and the Back-End file is updated without
affecting the client's existing data.

You will also need to add relinking code to relink the Front-End file
to the tables in the Back-End file. See this site to do that
automatically :-
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE_ReLink.mdb'

There is full documentation on both sites to explain the procedure
fully.

HTH

Peter Hibbs.

On Wed, 9 Apr 2008 06:56:49 -0600, "Karen"
wrote:

Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to Access
2007 also.

It is split into a FE and BE. I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access 2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. As you say, this is a great place to connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current success
BUT so far it has been sold through 'word of mouth' and the current users
just feel like old friends rather than the anonymous folks who may purchase
this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! Now that that is out of the way...

Deep breathes... What makes you think your application is NOT 'grown up'?
Doesn't sound like your users are complaining, quite the opposite! Sounds
like you're the one concerned it's not sophisticated enough for others to
use. Let's take a gander at the application (I don't mean literally)...

1. From your description, sounds like it is not split. In the scenario in
which it will be used I would recommend splitting it whether it is one user
or 20 users. My reasons are, if I have to deliver updates/changes/fixes I
don't need to have the end user send me their entire application and wait
while I import my modifications, all I have to do is send them a new front
end to 'pop' in place. There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need for
your Clients to have Access. (Not in Access 2007 those extensions are
free). HOWEVER, not so easy to get prior versions if you do not already own
them. You will need to look on reliable sites like Amazon.com.

3. You also might want to consider what version of Windows these
prospecitve Clients have. Do you have the ability to test on a Windows XP
machine, Windows Vista machine? Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. There are a ton of Access pages out there with all kinds of helpful
hints and tips. The MVP's and others in this group was sites you can go to
and read up on best practices and all kinds of cool stuff. All you have to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! We ALL started somewhere! For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! I have been
doing this for years and still feel like a beginner when I stand next to
these guys. Being a successful programmer is not always knowing the answer
but where to go get the answer! You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
(I am still trying to figure out how I can get it to make my coffee in the
morning!) While there are 'real' reasons to move to a SQL Server yours does
NOT sound like one of them. When and IF it every does, believe me someone
with way more experience and know how will point you there!

Thanks Peter,

I'll check out both

Karen

"Peter Hibbs" wrote in message
...
Karen,

As previous replies have said, you can update the Front-End file
easily by sending the client a new version. However, if you will need
to make changes to the Back-End file you need a different method.
Assuming that you cannot visit each client to make the necessary
changes you need to add some code to the Front-End which will make the
relevant changes to the Back-End files automatically.

There is code at this site :-
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE%20Update%20Utilit y.mdb'
which will do that for you. Just import the form, table and code
module into your database, add one line of code to your 'start up'
form and you are done. To add a new table or field to the Back-End you
just call up the BE Update form, enter the details of the table,
field, relationship, etc and the Back-End file is updated without
affecting the client's existing data.

You will also need to add relinking code to relink the Front-End file
to the tables in the Back-End file. See this site to do that
automatically :-
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE_ReLink.mdb'

There is full documentation on both sites to explain the procedure
fully.

HTH

Peter Hibbs.

On Wed, 9 Apr 2008 06:56:49 -0600, "Karen"
wrote:

Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to
Access
2007 also.

It is split into a FE and BE. I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access 2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. As you say, this is a great place to connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current success
BUT so far it has been sold through 'word of mouth' and the current users
just feel like old friends rather than the anonymous folks who may purchase
this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! Now that that is out of the way...

Deep breathes... What makes you think your application is NOT 'grown up'?
Doesn't sound like your users are complaining, quite the opposite! Sounds
like you're the one concerned it's not sophisticated enough for others to
use. Let's take a gander at the application (I don't mean literally)...

1. From your description, sounds like it is not split. In the scenario in
which it will be used I would recommend splitting it whether it is one user
or 20 users. My reasons are, if I have to deliver updates/changes/fixes I
don't need to have the end user send me their entire application and wait
while I import my modifications, all I have to do is send them a new front
end to 'pop' in place. There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need for
your Clients to have Access. (Not in Access 2007 those extensions are
free). HOWEVER, not so easy to get prior versions if you do not already
own
them. You will need to look on reliable sites like Amazon.com.

3. You also might want to consider what version of Windows these
prospecitve Clients have. Do you have the ability to test on a Windows XP
machine, Windows Vista machine? Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. There are a ton of Access pages out there with all kinds of helpful
hints and tips. The MVP's and others in this group was sites you can go to
and read up on best practices and all kinds of cool stuff. All you have to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! We ALL started somewhere! For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! I have been
doing this for years and still feel like a beginner when I stand next to
these guys. Being a successful programmer is not always knowing the answer
but where to go get the answer! You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
(I am still trying to figure out how I can get it to make my coffee in the
morning!) While there are 'real' reasons to move to a SQL Server yours
does
NOT sound like one of them. When and IF it every does, believe me someone
with way more experience and know how will point you there!

are you kidding me?

For 500 independend installations; single user-- they need a frontend
backend?

Sounds to me like SQL Server is a much simpler architecture.

-Aaron



On Apr 9, 8:29*am, "Karen" wrote:
Thanks Peter,

I'll check out both

Karen

"Peter Hibbs" wrote in message

...
Karen,

As previous replies have said, you can update the Front-End file
easily by sending the client a new version. However, if you will need
to make changes to the Back-End file you need a different method.
Assuming that you cannot visit each client to make the necessary
changes you need to add some code to the Front-End which will make the
relevant changes to the Back-End files automatically.

There is code at this site :-http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE%2...
which will do that for you. Just import the form, table and code
module into your database, add one line of code to your 'start up'
form and you are done. To add a new table or field to the Back-End you
just call up the BE Update form, enter the details of the table,
field, relationship, etc and the Back-End file is updated without
affecting the client's existing data.

You will also need to add relinking code to relink the Front-End file
to the tables in the Back-End file. See this site to do that
automatically :-http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE_R...

There is full documentation on both sites to explain the procedure
fully.

HTH

Peter Hibbs.

On Wed, 9 Apr 2008 06:56:49 -0600, "Karen"
wrote:



Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to
Access
2007 also.

It is split into a FE and BE. *I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access 2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. *As you say, this is a great place to connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current success
BUT so far it has been sold through 'word of mouth' and the current users
just feel like old friends rather than the anonymous folks who may purchase
this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! *Now that that is out of the way....

Deep breathes... *What makes you think your application is NOT 'grown up'?
Doesn't sound like your users are complaining, quite the opposite! *Sounds
like you're the one concerned it's not sophisticated enough for others to
use. *Let's take a gander at the application (I don't mean literally)....

1. *From your description, sounds like it is not split. *In the scenario in
which it will be used I would recommend splitting it whether it is one user
or 20 users. *My reasons are, if I have to deliver updates/changes/fixes I
don't need to have the end user send me their entire application and wait
while I import my modifications, all I have to do is send them a new front
end to 'pop' in place. *There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. *In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need for
your Clients to have Access. *(Not in Access 2007 those extensions are
free). *HOWEVER, not so easy to get prior versions if you do not already
own
them. *You will need to look on reliable sites like Amazon.com.

3. *You also might want to consider what version of Windows these
prospecitve Clients have. *Do you have the ability to test on a Windows XP
machine, Windows Vista machine? *Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. *There are a ton of Access pages out there with all kinds of helpful
hints and tips. *The MVP's and others in this group was sites you can go to
and read up on best practices and all kinds of cool stuff. *All you have to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! *We ALL started somewhere! *For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! *I have been
doing this for years and still feel like a beginner when I stand next to
these guys. *Being a successful programmer is not always knowing the answer
but where to go get the answer! *You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
(I am still trying to figure out how I can get it to make my coffee in the
morning!) *While there are 'real' reasons to move to a SQL Server yours
does
NOT sound like one of them. *When and IF it every does, believe me someone
with way more experience and know how will point you there!- Hide quoted text -

- Show quoted text -

I think that the package and deployment wizard does nothing but make
things more complex.

distribute AccessRt.msi and give them a file. It is that easy

Tell them 'not to install AccessRT if they've already for Access'

and for christ sakes-- 500 users, move to SQL Server!

-Aaron

On Apr 9, 8:28*am, "Karen" wrote:
Thanks Bruce,

I'm looking at the InstallCreator now. *I'll probably end up using the Package Solution in Access because I have to install the runtime and the Package Solution does that with voodoo I don't know how to find

I do have a way implemented where the FE checks to see if the BE needs an update BUT, as you can imagine, I avoid that at all costs.

Karen Hagerman

Faculty

University of Phoenix





206-309-0438 (Leave a Message)

* "BruceM" wrote in . ..
* I'm not sure how the FE Updater will work for users in far-flung locations.
* Perhaps it can be adapted, but it would need to check for a new version of
* the software in a web location rather than on the local intranet, which
* means the computer would need to be online, which may be unlikely if the
* laptop is brought to the actual inspection site. *Even if they are,
* connecting to the web site each time they start the app could be cumbersome,
* and is probably not necessary.
* It may be best to have a web site, and a button on the application to go
* there. *The web location could contain updates. *You could also notify
* registered users about updates via e-mail, and direct them to the web site.
* There is installer software that perhaps could help to automate updates.
* One version I have used, albeit on a local network, is he
*http://www.clickteam.com/eng/installcreator.php
* My experience with it is somewhat limited, but from what I have seen it is
* an excellent product.
* There are a lot of considerations with upgrades. *If you are just replacing
* the FE there is relatievely little to worry about, but if you need to update
* the BE then there will need to be a way to transfer data to the new BE..
* Keeping in mind that with Access you are developing an application, it could
* be that the application is somewhat platform-dependent. *That is, you may
* need a different version for Vista than for XP, 2000, etc. *Perhaps the
* run-time possibilities with Access 2007 can provide the flexibility you
* need, but my experience with Access 2007 hasn't gotten very far past trying
* to figure out the ribbon. *It is on my home machine, and I have had little
* opportunity to use it there so far.
* This posting is just a collection of thoughts and suggestions about what may
* be possible rather than an attempt to offer tested advice.

* "Karen" wrote in message
...
* Hi Gina,
*
* Thanks a lot for the response.
*
* This was originally developed with Access 2003 and I've updated it to
* Access 2007 also.
*
* It is split into a FE and BE. *I will definitely look at the FE updater;
* today I just re-issue a new FE but as the group grows that might become
* REALLY cumbersome with my method
*
* The Access 2003 version was distributed with the runtime, the Access 2007
* version will also be distributed with the runtime.
*
* I do have the Developer extensions and can test on both a 'clean' XP and
* Vista machine.
*
* When I first started on the original Access 2003 app I LIVED in the
* newsgroups and learned lots. *As you say, this is a great place to connect
* to those who have the experience.
*
* Yep, you're right, it probably is 'grown up' based on its current success
* BUT so far it has been sold through 'word of mouth' and the current users
* just feel like old friends rather than the anonymous folks who may
* purchase this based on an ad in a magazine.
*
* We'll see, I'd just like to be as prepared as possible to distribute a
* bullet-proof product to a larger group
*
* Karen
*
* "Gina Whipp" wrote in message
* ...
* Karen,
*
* First of all CONGRATS on your success! *Now that that is out of the way...
*
* Deep breathes... *What makes you think your application is NOT 'grown up'?
* Doesn't sound like your users are complaining, quite the opposite! *Sounds
* like you're the one concerned it's not sophisticated enough for others to
* use. *Let's take a gander at the application (I don't mean literally)...
*
* 1. *From your description, sounds like it is not split. *In the scenario
* in
* which it will be used I would recommend splitting it whether it is one
* user
* or 20 users. *My reasons are, if I have to deliver updates/changes/fixes I
* don't need to have the end user send me their entire application and wait
* while I import my modifications, all I have to do is send them a new front
* end to 'pop' in place. *There are additional items to consider, such as,
* what if there back-end is sitting a drive you don't have or a server you
* don't have. *In that case the is AutoFE Updater
* http://www.granite.ab.ca/access/downloadsindex.htm
*
* Implementing a Successful Multiuser Access/JET Application
* http://www.accessmvp.com/TWickerath/.../multiuser.htm
*
* Albert Kallal has an EXCELLENT article
* http://www.members.shaw.ca/AlbertKal...plit/index.htm
*
* 2. Depending on the version of Access you can purchase the 'Developer'
* extensions an distribute as a stand-alone thereby eliminating the need for
* your Clients to have Access. *(Not in Access 2007 those extensions are
* free). *HOWEVER, not so easy to get prior versions if you do not already
* own
* them. *You will need to look on reliable sites like Amazon.com.
*
* 3. *You also might want to consider what version of Windows these
* prospecitve Clients have. *Do you have the ability to test on a Windows XP
* machine, Windows Vista machine? *Though, if you application runs into
* trouble you can search the newsgroups, plenty of answers for people that
* have run into this very same issue.
*
* 4. *There are a ton of Access pages out there with all kinds of helpful
* hints and tips. *The MVP's and others in this group was sites you can go
* to
* and read up on best practices and all kinds of cool stuff. *All you have
* to
* do is 'follow the yellow brick road'!
*
* 5. AND MOST IMPORTANT!!! *We ALL started somewhere! *For alot of us, the
* newsgroups 'bailed' us out, helped us out and enlightened us! *I have been
* doing this for years and still feel like a beginner when I stand next to
* these guys. *Being a successful programmer is not always knowing the
* answer
* but where to go get the answer! *You came here to find out the best
* approach, you're already on the right track.
*
* Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
* (I am still trying to figure out how I can get it to make my coffee in the
* morning!) *While there are 'real' reasons to move to a SQL Server yours
* does
* NOT sound like one of them. *When and IF it every does, believe me someone
* with way more experience and know how will point you there!
*
* --
* Gina Whipp
*
* "I feel I have been denied critical, need to know, information!" - Tremors
* II
*
* "Karen" wrote in message
* ...
* Hi John,
*
* That's it exactly--------just have to figure out how to 'grow up' an
* application that has had unexpected success.
*
* Karen
*
* "John Marshall, MVP" wrote in message
* ...
* Looks like you have been bitten by our local troll. He is very myopic and
* will no matter what the question will reply with "Use SQL Server". I
* would
* strong avoid any recommendations he makes.
*
* What you are asking is not that hard and some of the regulars should be
* able
* to give you good advice. What you are looking for his information on
* packaging an Access application so that 500 independant users can use the
* application with their own data. They will not be sharing information.
*
* John... * *Visio MVP
*
* "Karen" wrote in message
* ...
* Thanks Aaron,
*
* I think I was not clear about 500 users, think of it as 1 application to
* 500 independent investigators. *I do think that it is likely that the
* next logical step will be upsizing the application to also work in small
* offices with a few users but.....................I have no intent to
* wander into the world of corporate use. *As you say, this application
* was designed for an independent investigator to automate both the
* collection and retention of commonly used data like Insurance
* companies/contacts/clients/addresses/phone numbers etc. *The resulting
* dataset changes from independent contractor to independent contractor.
*
* As far as "partnering with someone that is serious about Access"---that
* is really the gist of my original post. *I'm just an independent worker
* who created an application for a client, it was never my intent to
* create an application for 'the world' but, it is spreading and 'they'
* want to offer it now to a much larger community of independent
* investigators. Shoot, I think that's great, a little extra income would
* be great BUT I cannot overstress how 'ignorant' I feel in regards to how
* to do this well and properly
*
* Karen
*
* wrote in message
* ...
* Karen;
*
* Id reccomend one of two strategies:
*
* a) Focus on moving to SQL Server.
* b) partner with someone that is serious about Access. *I know of a
* very top-notch Access firm in Seattle.. they could help you with
* something like this.
...

read more »

We'll see, I'd just like to be as prepared as possible to
distribute a
bullet-proof product to a larger group

uh.. if you want bulletproof then move to ADP.

Access isn't reliable enough to run a single smoke detector

-Aaron



On Apr 9, 5:56*am, "Karen" wrote:
Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to Access
2007 also.

It is split into a FE and BE. *I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access 2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. *As you say, this is a great place to connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current success
BUT so far it has been sold through 'word of mouth' and the current users
just feel like old friends rather than the anonymous folks who may purchase
this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message

...
Karen,

First of all CONGRATS on your success! *Now that that is out of the way....

Deep breathes... *What makes you think your application is NOT 'grown up'?
Doesn't sound like your users are complaining, quite the opposite! *Sounds
like you're the one concerned it's not sophisticated enough for others to
use. *Let's take a gander at the application (I don't mean literally)...

1. *From your description, sounds like it is not split. *In the scenario in
which it will be used I would recommend splitting it whether it is one user
or 20 users. *My reasons are, if I have to deliver updates/changes/fixes I
don't need to have the end user send me their entire application and wait
while I import my modifications, all I have to do is send them a new front
end to 'pop' in place. *There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. *In that case the is AutoFE Updaterhttp://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Applicationhttp://www.accessmvp.com/TWickerath/articles/multiuser.htm

Albert Kallal has an EXCELLENT articlehttp://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need for
your Clients to have Access. *(Not in Access 2007 those extensions are
free). *HOWEVER, not so easy to get prior versions if you do not already own
them. *You will need to look on reliable sites like Amazon.com.

3. *You also might want to consider what version of Windows these
prospecitve Clients have. *Do you have the ability to test on a Windows XP
machine, Windows Vista machine? *Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. *There are a ton of Access pages out there with all kinds of helpful
hints and tips. *The MVP's and others in this group was sites you can go to
and read up on best practices and all kinds of cool stuff. *All you have to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! *We ALL started somewhere! *For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! *I have been
doing this for years and still feel like a beginner when I stand next to
these guys. *Being a successful programmer is not always knowing the answer
but where to go get the answer! *You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
(I am still trying to figure out how I can get it to make my coffee in the
morning!) *While there are 'real' reasons to move to a SQL Server yours does
NOT sound like one of them. *When and IF it every does, believe me someone
with way more experience and know how will point you there!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

"Karen" wrote in message

...



Hi John,

That's it exactly--------just have to figure out how to 'grow up' an
application that has had unexpected success.

Karen

"John Marshall, MVP" wrote in message
...
Looks like you have been bitten by our local troll. He is very myopic and
will no matter what the question will reply with "Use SQL Server". I would
strong avoid any recommendations he makes.

What you are asking is not that hard and some of the regulars should be
able
to give you good advice. What you are looking for his information on
packaging an Access application so that 500 independant users can use the
application with their own data. They will not be sharing information.

John... * *Visio MVP

"Karen" wrote in message
...
Thanks Aaron,

I think I was not clear about 500 users, think of it as 1 application to
500 independent investigators. *I do think that it is likely that the
next logical step will be upsizing the application to also work in small
offices with a few users but.....................I have no intent to
wander into the world of corporate use. *As you say, this application was
designed for an independent investigator to automate both the collection
and retention of commonly used data like Insurance
companies/contacts/clients/addresses/phone numbers etc. *The resulting
dataset changes from independent contractor to independent contractor.

As far as "partnering with someone that is serious about Access"---that
is really the gist of my original post. *I'm just an independent worker
who created an application for a client, it was never my intent to create
an application for 'the world' but, it is spreading and 'they' want to
offer it now to a much larger community of independent investigators.
Shoot, I think that's great, a little extra income would be great BUT I
cannot overstress how 'ignorant' I feel in regards to how to do this well
and properly

Karen

wrote in message
....
Karen;

Id reccomend one of two strategies:

a) Focus on moving to SQL Server.
b) partner with someone that is serious about Access. *I know of a
very top-notch Access firm in Seattle.. they could help you with
something like this.

But don't count on scaling to 500 users easily.

If you want something that with much throughput; you should just pick
up a copy of dreamweaver; and copy the forms; use wizards to make
webpages. *Access just isn't designed for 500 users; and there isn't a
person in the world that can make a flawless (fast) solution using MDB
linked tables to SQL Server that supports 500 users.

Are you going to just keep SQL on one server?
Or one server at each office?
Or a local copy of SQL Server on every laptop?

The Office 2000 Developer Editon has all the tools that you need to
deploy SQL Server to desktops for local storage.
Then you would just need to configure replication.

The VB 2005 Express Edition has all the tools to do this also.. it is
free and easy. *That might help you to minimize a lot of the
complexities of something like this.

I mean-- these are fire inspectors that run around to different sites
with a laptop right?
It's not like they can inspect across the internet; right?

I just think that you'd be best served by focusing on the SQL Server
side of the equation. *Do that, do it right for a year-- before diving
into something like this.

In general-- Access is _NOT_ a professional software development
platform. *Yes; some companies use it quite successfully. *But if
you're talking about something like this-- do you even know the
security ramifications of this data? I think that security on this
type of data is probably 100 times more important than it first seems.

Upsizing a MDB database to SQL Server isnt' going to work with that
many users-- unless you move to ADP.

Sorry-- but those are the facts.

-Aaron

On Apr 8, 2:09 pm, "Karen" wrote:
Hi All,

I've got an Access application that was originally developed for a
customer
who is an independent fire investigator. The same customer has now
'sold'
the app to fellow independent investigators, both other fire
investigators
and other insurance investigators and it has been 'in the field' for a
little more than four years.

The original customer who paid for the development and has been sharing
it
with his buddies now wants to place an ad in an industry-specific
publication and start selling this app.

Quite frankly, although the app has worked famously for the current
users
and support of those customers has been negligible, distributing this to
a
wider audience scares the heck out of me. I'm proud of the app and the
enthusiasm that the current users have for it but there will be a HUGE
difference between 50 users and 500 users. So.............I need to
consider what it takes to distribute this. Some of the questions that
keep
me up at night:

Although currently a one-user application, it would also make sense to
develop a means to let an entire
office use the application. The user front-end would talk to a SQL
Server backend.
Do I use the developer tools to develop the

...

read more »- Hide quoted text -

- Show quoted text -

You bet. I can update the frontend and not touch the user's data.

--
Karen
wrote in message
...
are you kidding me?

For 500 independend installations; single user-- they need a frontend
backend?

Sounds to me like SQL Server is a much simpler architecture.

-Aaron



On Apr 9, 8:29 am, "Karen" wrote:
Thanks Peter,

I'll check out both

Karen

"Peter Hibbs" wrote in message

...
Karen,

As previous replies have said, you can update the Front-End file
easily by sending the client a new version. However, if you will need
to make changes to the Back-End file you need a different method.
Assuming that you cannot visit each client to make the necessary
changes you need to add some code to the Front-End which will make the
relevant changes to the Back-End files automatically.

There is code at this site
:-http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE%2...
which will do that for you. Just import the form, table and code
module into your database, add one line of code to your 'start up'
form and you are done. To add a new table or field to the Back-End you
just call up the BE Update form, enter the details of the table,
field, relationship, etc and the Back-End file is updated without
affecting the client's existing data.

You will also need to add relinking code to relink the Front-End file
to the tables in the Back-End file. See this site to do that
automatically
:-http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='BE_R...

There is full documentation on both sites to explain the procedure
fully.

HTH

Peter Hibbs.

On Wed, 9 Apr 2008 06:56:49 -0600, "Karen"
wrote:



Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to
Access
2007 also.

It is split into a FE and BE. I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access 2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. As you say, this is a great place to connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current success
BUT so far it has been sold through 'word of mouth' and the current users
just feel like old friends rather than the anonymous folks who may
purchase
this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! Now that that is out of the way...

Deep breathes... What makes you think your application is NOT 'grown up'?
Doesn't sound like your users are complaining, quite the opposite! Sounds
like you're the one concerned it's not sophisticated enough for others to
use. Let's take a gander at the application (I don't mean literally)...

1. From your description, sounds like it is not split. In the scenario in
which it will be used I would recommend splitting it whether it is one
user
or 20 users. My reasons are, if I have to deliver updates/changes/fixes I
don't need to have the end user send me their entire application and wait
while I import my modifications, all I have to do is send them a new
front
end to 'pop' in place. There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need
for
your Clients to have Access. (Not in Access 2007 those extensions are
free). HOWEVER, not so easy to get prior versions if you do not already
own
them. You will need to look on reliable sites like Amazon.com.

3. You also might want to consider what version of Windows these
prospecitve Clients have. Do you have the ability to test on a Windows XP
machine, Windows Vista machine? Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. There are a ton of Access pages out there with all kinds of helpful
hints and tips. The MVP's and others in this group was sites you can go
to
and read up on best practices and all kinds of cool stuff. All you have
to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! We ALL started somewhere! For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! I have been
doing this for years and still feel like a beginner when I stand next to
these guys. Being a successful programmer is not always knowing the
answer
but where to go get the answer! You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL Server!
(I am still trying to figure out how I can get it to make my coffee in
the
morning!) While there are 'real' reasons to move to a SQL Server yours
does
NOT sound like one of them. When and IF it every does, believe me someone
with way more experience and know how will point you there!- Hide quoted
text -

- Show quoted text -

"Karen" wrote in message
...

Although currently a one-user application, it would also make sense to
develop a means to let an entire
office use the application. The user front-end would talk to a SQL
Server backend.

If only about 2-10 users in the same office will be using the appliation,
then you'll likely not need to deploy and use SQL server in this situation.


Do I use the developer tools to develop the installation package or
migrate to InstallShield or Wise

The first question I would ask right now is have you been in issuing the
many bug fixes, updates, and satisfying the many requests that those people
have for new reports, or even modifying a report?

Other issues of wide distribution might require you to add the ability to
display the company name or particular branding information for that one
organization on the each report. (and perhaps you might wanna add a button
to your reports menu bar that allows you to be mail or send the particular
document your viewing as a pdf file). Once again only you can answer these
types of questions.

Another issue is things like defaults in forms. I have a form with setup
information for the particular company (name, address etc). I also have a
form that allows me to setup the defaults for things like State/Province and
city. Thus when the person enters a new record, the default city field is
"their" city, not the one I choose during development. Same goes for the
area code default, and state/province default. What I'm suggesting here is
for you to look at any of the values in your application that you perhaps
hard coded inside of the code, or have placed inside of the forms design
mode for defaults. This issue may or may not matter for your application,
but you want to sit down and give it some thought in terms of how these
things work now.

What this means is you want advoid hard coding some of the defaults in MS
access (forms, or tables). You also have to assuem it is unreasonable to
think that you're end users are going to be able to modify the code in the
system that you're deploying.

What this also means is that you likely using a split database right? If
your application is not split, then how have you been issuing the many bug
fixes, updates etc. for new features? So, how have you been updating these
people software now? I should point out that no installer tool will solve
this problem for you, and you have to have some design considerations in
your application to allow you to issue a bug fixes and updates to your
software in the field. This usually means your application has to be split.

I cannot stress how important it is to come up with a system to manage the
updating of this software on users machines you never seen. Furthermore it
sounds like you have some experience with the application being deployed in
the field right now. Note that with wider distribution you will have to
address the issues like different screen sizes (screen resolution), and also
things like different kinds of printers (about the only advice I can mention
with different kinds of printers is to make sure that you been very liberal
with your margins in your reports.

The other issue is to you plan to deploy the application on machines without
an actual copy of a MS access installed? If that's the case, then you'll
want to consider using the runtime package and deployment system that is
available for MS access. Note that these runtime systems do not have a means
to update and maintain your software in the field for you. However, the
runtime system does allow you to build a standard windows install that will
allow you to create a CD, or even a web download in which users can install
the software.

If you're going to distribute to machines that you've never used before, or
machines that have a very large variety of different versions of office,
then you're going to have a lot of problems in this regards. The reason for
this is a MS access does not play well when other versions of MS access are
already installed on the particular target computer. If this is the case,
then you have to do two things:

1) heed the above advice about making some means of updating your software
in the field.

2) If you're going to be looking at wide distribution on machines that you
don't know what version of office they have, then you have to come up with a
fairly robust and independent install of the MS access that will not damage
or interfere with the existing versions of office, or even MS access.
Installing multiple versions of MS access on the same machine tends to be
quite problematic. As a general rule I can to avoid this type of setup
altogether.

However if I was going to widely distribute to a lot of different machines,
and reduce the problems of support and installing the software, then I would
recommend you purchase some install scripts for the runtime deplopyment
system for MS access (the ones that come with ms-access package system are
NOT up to quality for commercial distribution of your application).

You can find install scripts he

www.sagekey.com

Where do I look for deployment specialists who are familiar with Access
applications?

How difficult it is to deploy your application is going to depend on how
well it's been designed now, and what you done so far to issue updates. Keep
in mind the issue of installing the application, and the issue of updating
new updates for bug fixes are not always one and the same thing.

The other issue of course is to do you want to install the application on
machines that don't necessarily have a version of the MS access installed?
Once again the amount of work to do this is going to be based on how much
effort and time you've put into the application now. For example do you hide
all in the additional menus and options you see in the MS access interface?
After all it might be too much that you require the users to go out and be
trained on how to use MS access. So, if you hide all things like the query
builder, and report writer from their prying eyes you make the application
far more user friendly and easy to use. For example, I don't allow my users
to see any of the query builder or any of the internals of my applications.
Take a quick read of the following as to how I allow users to to enter
things like date ranges and other parameters for report's:

http://www.members.shaw.ca/AlbertKal.../ridesrpt.html

Another issue is have you design the user interface well enough to reduce
the training costs of people using this application? I give some hints and
thoughts on building a user interface that reduces your training costs by
substantial amounts he

http://www.members.shaw.ca/AlbertKal...erFriendly.htm


If not the newsgroups then how do I find those 'experts' who know how to
take the next step? The newsgroups are great but I'm up for finding the
right 'experts' to contract with; just have no idea where to look

As mentioned if you are looking to purchase some deployment technologies,
sagekey is a good starting point. However the issues we'll need the most
work is to ensure that you've built and designed your system that reduces
training costs, should hide the MS access interface, should be split, should
likely allow you to deploy to users without MS access, and have designed a
means to update both the application part (front end), and the table
structures in the back end of your system by users you'll never meet in
person.


I know many of you have developed robust applications, what is the next
step?

As mentioned start by answering some of the questions above like do have you
run a split system? I talk about running a split database in the following
article of mine:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

Of course one thing always leads to the next step, and once you've learned
to split your database, then I'm sure you'll have cobbled together some code
to automatically re-link the front end to the back end. Same code is he

http://www.mvps.org/access/tables/tbl0009.h

How much work all of the above steps are really depends on how you've done
things now. For example to use the MS access runtime, you have to build and
provide your own menu system and interface. Since in all of my applications
I've always hidden the built in access menus, then deployment using the
runtime for me was no extra work at all. However if you've not been hiding
the MS access interface in your example appcation, then you have to address
this issue, Especially if you plan to use the runtime. (and of course if you
hide most of the MS access interface, then new users who will not be
overwhelmed with all kinds of menu options and features that they really
don't need to use).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

You aren't paying attention. The OP said there may be 500 users, but they
are not all using the same data. That is, there could be a fairly large
number of users, but each has their own copy of the program. There may be a
few users, but not 500 using the same copy of the program. As with personal
financial management software, there is no need for centralized data
storage. Please do not debate this point with me, as I am only paraphrasing
what I remember reading elsewhere in this thread.
Regarding the installer program, I mentioned it as something that has worked
well in other situations, and may be of use here. In my case it simplified
installation, but I am not saying it is the solution in all situations.

wrote in message
...
I think that the package and deployment wizard does nothing but make
things more complex.

distribute AccessRt.msi and give them a file. It is that easy

Tell them 'not to install AccessRT if they've already for Access'

and for christ sakes-- 500 users, move to SQL Server!

-Aaron

On Apr 9, 8:28 am, "Karen" wrote:
Thanks Bruce,

I'm looking at the InstallCreator now. I'll probably end up using the
Package Solution in Access because I have to install the runtime and the
Package Solution does that with voodoo I don't know how to find

I do have a way implemented where the FE checks to see if the BE needs an
update BUT, as you can imagine, I avoid that at all costs.

Karen Hagerman

Faculty

University of Phoenix





206-309-0438 (Leave a Message)

"BruceM" wrote in
. ..
I'm not sure how the FE Updater will work for users in far-flung
locations.
Perhaps it can be adapted, but it would need to check for a new version of
the software in a web location rather than on the local intranet, which
means the computer would need to be online, which may be unlikely if the
laptop is brought to the actual inspection site. Even if they are,
connecting to the web site each time they start the app could be
cumbersome,
and is probably not necessary.
It may be best to have a web site, and a button on the application to go
there. The web location could contain updates. You could also notify
registered users about updates via e-mail, and direct them to the web
site.
There is installer software that perhaps could help to automate updates.
One version I have used, albeit on a local network, is he
http://www.clickteam.com/eng/installcreator.php
My experience with it is somewhat limited, but from what I have seen it is
an excellent product.
There are a lot of considerations with upgrades. If you are just replacing
the FE there is relatievely little to worry about, but if you need to
update
the BE then there will need to be a way to transfer data to the new BE.
Keeping in mind that with Access you are developing an application, it
could
be that the application is somewhat platform-dependent. That is, you may
need a different version for Vista than for XP, 2000, etc. Perhaps the
run-time possibilities with Access 2007 can provide the flexibility you
need, but my experience with Access 2007 hasn't gotten very far past
trying
to figure out the ribbon. It is on my home machine, and I have had little
opportunity to use it there so far.
This posting is just a collection of thoughts and suggestions about what
may
be possible rather than an attempt to offer tested advice.

"Karen" wrote in message
...
Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to
Access 2007 also.

It is split into a FE and BE. I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access
2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. As you say, this is a great place to
connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current
success
BUT so far it has been sold through 'word of mouth' and the current
users
just feel like old friends rather than the anonymous folks who may
purchase this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! Now that that is out of the
way...

Deep breathes... What makes you think your application is NOT 'grown
up'?
Doesn't sound like your users are complaining, quite the opposite!
Sounds
like you're the one concerned it's not sophisticated enough for others
to
use. Let's take a gander at the application (I don't mean literally)...

1. From your description, sounds like it is not split. In the scenario
in
which it will be used I would recommend splitting it whether it is one
user
or 20 users. My reasons are, if I have to deliver updates/changes/fixes
I
don't need to have the end user send me their entire application and
wait
while I import my modifications, all I have to do is send them a new
front
end to 'pop' in place. There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need
for
your Clients to have Access. (Not in Access 2007 those extensions are
free). HOWEVER, not so easy to get prior versions if you do not already
own
them. You will need to look on reliable sites like Amazon.com.

3. You also might want to consider what version of Windows these
prospecitve Clients have. Do you have the ability to test on a Windows
XP
machine, Windows Vista machine? Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. There are a ton of Access pages out there with all kinds of helpful
hints and tips. The MVP's and others in this group was sites you can go
to
and read up on best practices and all kinds of cool stuff. All you have
to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! We ALL started somewhere! For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! I have
been
doing this for years and still feel like a beginner when I stand next to
these guys. Being a successful programmer is not always knowing the
answer
but where to go get the answer! You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL
Server!
(I am still trying to figure out how I can get it to make my coffee in
the
morning!) While there are 'real' reasons to move to a SQL Server yours
does
NOT sound like one of them. When and IF it every does, believe me
someone
with way more experience and know how will point you there!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" -
Tremors
II

"Karen" wrote in message
...
Hi John,

That's it exactly--------just have to figure out how to 'grow up' an
application that has had unexpected success.

Karen

"John Marshall, MVP" wrote in message
...
Looks like you have been bitten by our local troll. He is very myopic
and
will no matter what the question will reply with "Use SQL Server". I
would
strong avoid any recommendations he makes.

What you are asking is not that hard and some of the regulars should be
able
to give you good advice. What you are looking for his information on
packaging an Access application so that 500 independant users can use
the
application with their own data. They will not be sharing information.

John... Visio MVP

"Karen" wrote in message
...
Thanks Aaron,

I think I was not clear about 500 users, think of it as 1 application
to
500 independent investigators. I do think that it is likely that the
next logical step will be upsizing the application to also work in
small
offices with a few users but.....................I have no intent to
wander into the world of corporate use. As you say, this application
was designed for an independent investigator to automate both the
collection and retention of commonly used data like Insurance
companies/contacts/clients/addresses/phone numbers etc. The resulting
dataset changes from independent contractor to independent contractor.

As far as "partnering with someone that is serious about
Access"---that
is really the gist of my original post. I'm just an independent worker
who created an application for a client, it was never my intent to
create an application for 'the world' but, it is spreading and 'they'
want to offer it now to a much larger community of independent
investigators. Shoot, I think that's great, a little extra income
would
be great BUT I cannot overstress how 'ignorant' I feel in regards to
how
to do this well and properly

Karen

wrote in message
...
Karen;

Id reccomend one of two strategies:

a) Focus on moving to SQL Server.
b) partner with someone that is serious about Access. I know of a
very top-notch Access firm in Seattle.. they could help you with
something like this.
...

read more »

Thanks Bruce,

You have the picture right, 500 users using their own copy of the
application with their own data. I do appreciate the suggestion about
InstallCreator and am looking at it also along with the 'new' Package
Solution in Access 2007

--
Karen

"BruceM" wrote in message
...
You aren't paying attention. The OP said there may be 500 users, but they
are not all using the same data. That is, there could be a fairly large
number of users, but each has their own copy of the program. There may be a
few users, but not 500 using the same copy of the program. As with personal
financial management software, there is no need for centralized data
storage. Please do not debate this point with me, as I am only paraphrasing
what I remember reading elsewhere in this thread.
Regarding the installer program, I mentioned it as something that has worked
well in other situations, and may be of use here. In my case it simplified
installation, but I am not saying it is the solution in all situations.

wrote in message
...
I think that the package and deployment wizard does nothing but make
things more complex.

distribute AccessRt.msi and give them a file. It is that easy

Tell them 'not to install AccessRT if they've already for Access'

and for christ sakes-- 500 users, move to SQL Server!

-Aaron

On Apr 9, 8:28 am, "Karen" wrote:
Thanks Bruce,

I'm looking at the InstallCreator now. I'll probably end up using the
Package Solution in Access because I have to install the runtime and the
Package Solution does that with voodoo I don't know how to find

I do have a way implemented where the FE checks to see if the BE needs an
update BUT, as you can imagine, I avoid that at all costs.

Karen Hagerman

Faculty

University of Phoenix





206-309-0438 (Leave a Message)

"BruceM" wrote in
. ..
I'm not sure how the FE Updater will work for users in far-flung
locations.
Perhaps it can be adapted, but it would need to check for a new version of
the software in a web location rather than on the local intranet, which
means the computer would need to be online, which may be unlikely if the
laptop is brought to the actual inspection site. Even if they are,
connecting to the web site each time they start the app could be
cumbersome,
and is probably not necessary.
It may be best to have a web site, and a button on the application to go
there. The web location could contain updates. You could also notify
registered users about updates via e-mail, and direct them to the web
site.
There is installer software that perhaps could help to automate updates.
One version I have used, albeit on a local network, is he
http://www.clickteam.com/eng/installcreator.php
My experience with it is somewhat limited, but from what I have seen it is
an excellent product.
There are a lot of considerations with upgrades. If you are just replacing
the FE there is relatievely little to worry about, but if you need to
update
the BE then there will need to be a way to transfer data to the new BE.
Keeping in mind that with Access you are developing an application, it
could
be that the application is somewhat platform-dependent. That is, you may
need a different version for Vista than for XP, 2000, etc. Perhaps the
run-time possibilities with Access 2007 can provide the flexibility you
need, but my experience with Access 2007 hasn't gotten very far past
trying
to figure out the ribbon. It is on my home machine, and I have had little
opportunity to use it there so far.
This posting is just a collection of thoughts and suggestions about what
may
be possible rather than an attempt to offer tested advice.

"Karen" wrote in message
...
Hi Gina,

Thanks a lot for the response.

This was originally developed with Access 2003 and I've updated it to
Access 2007 also.

It is split into a FE and BE. I will definitely look at the FE updater;
today I just re-issue a new FE but as the group grows that might become
REALLY cumbersome with my method

The Access 2003 version was distributed with the runtime, the Access
2007
version will also be distributed with the runtime.

I do have the Developer extensions and can test on both a 'clean' XP and
Vista machine.

When I first started on the original Access 2003 app I LIVED in the
newsgroups and learned lots. As you say, this is a great place to
connect
to those who have the experience.

Yep, you're right, it probably is 'grown up' based on its current
success
BUT so far it has been sold through 'word of mouth' and the current
users
just feel like old friends rather than the anonymous folks who may
purchase this based on an ad in a magazine.

We'll see, I'd just like to be as prepared as possible to distribute a
bullet-proof product to a larger group

Karen

"Gina Whipp" wrote in message
...
Karen,

First of all CONGRATS on your success! Now that that is out of the
way...

Deep breathes... What makes you think your application is NOT 'grown
up'?
Doesn't sound like your users are complaining, quite the opposite!
Sounds
like you're the one concerned it's not sophisticated enough for others
to
use. Let's take a gander at the application (I don't mean literally)...

1. From your description, sounds like it is not split. In the scenario
in
which it will be used I would recommend splitting it whether it is one
user
or 20 users. My reasons are, if I have to deliver updates/changes/fixes
I
don't need to have the end user send me their entire application and
wait
while I import my modifications, all I have to do is send them a new
front
end to 'pop' in place. There are additional items to consider, such as,
what if there back-end is sitting a drive you don't have or a server you
don't have. In that case the is AutoFE Updater
http://www.granite.ab.ca/access/downloadsindex.htm

Implementing a Successful Multiuser Access/JET Application
http://www.accessmvp.com/TWickerath/.../multiuser.htm

Albert Kallal has an EXCELLENT article
http://www.members.shaw.ca/AlbertKal...plit/index.htm

2. Depending on the version of Access you can purchase the 'Developer'
extensions an distribute as a stand-alone thereby eliminating the need
for
your Clients to have Access. (Not in Access 2007 those extensions are
free). HOWEVER, not so easy to get prior versions if you do not already
own
them. You will need to look on reliable sites like Amazon.com.

3. You also might want to consider what version of Windows these
prospecitve Clients have. Do you have the ability to test on a Windows
XP
machine, Windows Vista machine? Though, if you application runs into
trouble you can search the newsgroups, plenty of answers for people that
have run into this very same issue.

4. There are a ton of Access pages out there with all kinds of helpful
hints and tips. The MVP's and others in this group was sites you can go
to
and read up on best practices and all kinds of cool stuff. All you have
to
do is 'follow the yellow brick road'!

5. AND MOST IMPORTANT!!! We ALL started somewhere! For alot of us, the
newsgroups 'bailed' us out, helped us out and enlightened us! I have
been
doing this for years and still feel like a beginner when I stand next to
these guys. Being a successful programmer is not always knowing the
answer
but where to go get the answer! You came here to find out the best
approach, you're already on the right track.

Lastly, please ignore Aaron, his solution to EVERYTHING is an SQL
Server!
(I am still trying to figure out how I can get it to make my coffee in
the
morning!) While there are 'real' reasons to move to a SQL Server yours
does
NOT sound like one of them. When and IF it every does, believe me
someone
with way more experience and know how will point you there!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" -
Tremors
II

"Karen" wrote in message
...
Hi John,

That's it exactly--------just have to figure out how to 'grow up' an
application that has had unexpected success.

Karen

"John Marshall, MVP" wrote in message
...
Looks like you have been bitten by our local troll. He is very myopic
and
will no matter what the question will reply with "Use SQL Server". I
would
strong avoid any recommendations he makes.

What you are asking is not that hard and some of the regulars should be
able
to give you good advice. What you are looking for his information on
packaging an Access application so that 500 independant users can use
the
application with their own data. They will not be sharing information.

John... Visio MVP

"Karen" wrote in message
...
Thanks Aaron,

I think I was not clear about 500 users, think of it as 1 application
to
500 independent investigators. I do think that it is likely that the
next logical step will be upsizing the application to also work in
small
offices with a few users but.....................I have no intent to
wander into the world of corporate use. As you say, this application
was designed for an independent investigator to automate both the
collection and retention of commonly used data like Insurance
companies/contacts/clients/addresses/phone numbers etc. The resulting
dataset changes from independent contractor to independent contractor.

As far as "partnering with someone that is serious about
Access"---that
is really the gist of my original post. I'm just an independent worker
who created an application for a client, it was never my intent to
create an application for 'the world' but, it is spreading and 'they'
want to offer it now to a much larger community of independent
investigators. Shoot, I think that's great, a little extra income
would
be great BUT I cannot overstress how 'ignorant' I feel in regards to
how
to do this well and properly

Karen

wrote in message
...
Karen;

Id reccomend one of two strategies:

a) Focus on moving to SQL Server.
b) partner with someone that is serious about Access. I know of a
very top-notch Access firm in Seattle.. they could help you with
something like this.
...

read more »

Albert,

A great list of concerns so:


The first question I would ask right now is have you been in issuing the
many bug fixes, updates, and satisfying the many requests that those people
have for new reports, or even modifying a report?

I have been providing a link on a webpage to download the 'new' front-end
and sent emails to customers to update by downloading the new front-end.
There have been queries about 'new' reports. The original Access 2003 app
pushed the data to Word templates, so does the updated Access 2007 app. I
just 'found' your code for the mail merge posted by Gina earlier and am
looking into it. I was using bookmarks so...................we learn
something every day Up to this point I've just avoided the subject of
'new' reports because these customers want Word files to distribute their
reports to customers. I do have a maintenance feature in the app that
allows customers to modify specific fields in the templates such as
inserting a company logo or adding specific verbiage they want on all
reports.

Another issue is things like defaults in forms. I have a form with setup
information for the particular company (name, address etc). I also have a
form that allows me to setup the defaults for things like State/Province and
city. Thus when the person enters a new record, the default city field is
"their" city, not the one I choose during development. Same goes for the
area code default, and state/province default. What I'm suggesting here is
for you to look at any of the values in your application that you perhaps
hard coded inside of the code, or have placed inside of the forms design
mode for defaults. This issue may or may not matter for your application,
but you want to sit down and give it some thought in terms of how these
things work now.

Great suggestion and I'll do it; it would definitely be a boost to the
instant usability; right now they do have to change values in a few places.

What this also means is that you likely using a split database right? If
your application is not split, then how have you been issuing the many bug
fixes, updates etc. for new features?

The app is indeed split into front-end and back-end precisely so the
front-end can be updated without touching the user's data. I also check to
see if the back-end needs updating but have only done that once in these
past four years.............I HATE playing with the data side of the app
once it is in use

The other issue is to you plan to deploy the application on machines
without
an actual copy of a MS access installed? If that's the case, then you'll
want to consider using the runtime package and deployment system that is
available for MS access.

I do deploy with the relevant runtime for both versions.

If you're going to be looking at wide distribution on machines that you
don't know what version of office they have, then you have to come up with a
fairly robust and independent install of the MS access that will not damage
or interfere with the existing versions of office, or even MS access. and
..then I would
recommend you purchase some install scripts for the runtime deplopyment
system for MS access (the ones that come with ms-access package system are
NOT up to quality for commercial distribution of your application).

I will definitely look at Sagekey and the other links you provided. These
customers tend to be experts in their field but computer
semi-literate----------simple and bug-free (at least that's the goal) is the
only way to go. I have definitely been puzzling over how to ENSURE that a
customer with Office 2003 gets the Access 2003 app and a customer with
Office 2007 gets the Access 2007 version

Thanks very much for the thorough review of what I think to be thinking of,
I appreciate it the help very much.

--
Karen
"Albert D. Kallal" wrote in message
...
"Karen" wrote in message
...

Although currently a one-user application, it would also make sense to
develop a means to let an entire
office use the application. The user front-end would talk to a SQL
Server backend.

If only about 2-10 users in the same office will be using the appliation,
then you'll likely not need to deploy and use SQL server in this situation.


Do I use the developer tools to develop the installation package or
migrate to InstallShield or Wise

The first question I would ask right now is have you been in issuing the
many bug fixes, updates, and satisfying the many requests that those people
have for new reports, or even modifying a report?

Other issues of wide distribution might require you to add the ability to
display the company name or particular branding information for that one
organization on the each report. (and perhaps you might wanna add a button
to your reports menu bar that allows you to be mail or send the particular
document your viewing as a pdf file). Once again only you can answer these
types of questions.

Another issue is things like defaults in forms. I have a form with setup
information for the particular company (name, address etc). I also have a
form that allows me to setup the defaults for things like State/Province and
city. Thus when the person enters a new record, the default city field is
"their" city, not the one I choose during development. Same goes for the
area code default, and state/province default. What I'm suggesting here is
for you to look at any of the values in your application that you perhaps
hard coded inside of the code, or have placed inside of the forms design
mode for defaults. This issue may or may not matter for your application,
but you want to sit down and give it some thought in terms of how these
things work now.

What this means is you want advoid hard coding some of the defaults in MS
access (forms, or tables). You also have to assuem it is unreasonable to
think that you're end users are going to be able to modify the code in the
system that you're deploying.

What this also means is that you likely using a split database right? If
your application is not split, then how have you been issuing the many bug
fixes, updates etc. for new features? So, how have you been updating these
people software now? I should point out that no installer tool will solve
this problem for you, and you have to have some design considerations in
your application to allow you to issue a bug fixes and updates to your
software in the field. This usually means your application has to be split.

I cannot stress how important it is to come up with a system to manage the
updating of this software on users machines you never seen. Furthermore it
sounds like you have some experience with the application being deployed in
the field right now. Note that with wider distribution you will have to
address the issues like different screen sizes (screen resolution), and also
things like different kinds of printers (about the only advice I can mention
with different kinds of printers is to make sure that you been very liberal
with your margins in your reports.

The other issue is to you plan to deploy the application on machines without
an actual copy of a MS access installed? If that's the case, then you'll
want to consider using the runtime package and deployment system that is
available for MS access. Note that these runtime systems do not have a means
to update and maintain your software in the field for you. However, the
runtime system does allow you to build a standard windows install that will
allow you to create a CD, or even a web download in which users can install
the software.

If you're going to distribute to machines that you've never used before, or
machines that have a very large variety of different versions of office,
then you're going to have a lot of problems in this regards. The reason for
this is a MS access does not play well when other versions of MS access are
already installed on the particular target computer. If this is the case,
then you have to do two things:

1) heed the above advice about making some means of updating your software
in the field.

2) If you're going to be looking at wide distribution on machines that you
don't know what version of office they have, then you have to come up with a
fairly robust and independent install of the MS access that will not damage
or interfere with the existing versions of office, or even MS access.
Installing multiple versions of MS access on the same machine tends to be
quite problematic. As a general rule I can to avoid this type of setup
altogether.

However if I was going to widely distribute to a lot of different machines,
and reduce the problems of support and installing the software, then I would
recommend you purchase some install scripts for the runtime deplopyment
system for MS access (the ones that come with ms-access package system are
NOT up to quality for commercial distribution of your application).

You can find install scripts he

www.sagekey.com

Where do I look for deployment specialists who are familiar with Access
applications?

How difficult it is to deploy your application is going to depend on how
well it's been designed now, and what you done so far to issue updates. Keep
in mind the issue of installing the application, and the issue of updating
new updates for bug fixes are not always one and the same thing.

The other issue of course is to do you want to install the application on
machines that don't necessarily have a version of the MS access installed?
Once again the amount of work to do this is going to be based on how much
effort and time you've put into the application now. For example do you hide
all in the additional menus and options you see in the MS access interface?
After all it might be too much that you require the users to go out and be
trained on how to use MS access. So, if you hide all things like the query
builder, and report writer from their prying eyes you make the application
far more user friendly and easy to use. For example, I don't allow my users
to see any of the query builder or any of the internals of my applications.
Take a quick read of the following as to how I allow users to to enter
things like date ranges and other parameters for report's:

http://www.members.shaw.ca/AlbertKal.../ridesrpt.html

Another issue is have you design the user interface well enough to reduce
the training costs of people using this application? I give some hints and
thoughts on building a user interface that reduces your training costs by
substantial amounts he

http://www.members.shaw.ca/AlbertKal...erFriendly.htm


If not the newsgroups then how do I find those 'experts' who know how to
take the next step? The newsgroups are great but I'm up for finding the
right 'experts' to contract with; just have no idea where to look

As mentioned if you are looking to purchase some deployment technologies,
sagekey is a good starting point. However the issues we'll need the most
work is to ensure that you've built and designed your system that reduces
training costs, should hide the MS access interface, should be split, should
likely allow you to deploy to users without MS access, and have designed a
means to update both the application part (front end), and the table
structures in the back end of your system by users you'll never meet in
person.


I know many of you have developed robust applications, what is the next
step?

As mentioned start by answering some of the questions above like do have you
run a split system? I talk about running a split database in the following
article of mine:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

Of course one thing always leads to the next step, and once you've learned
to split your database, then I'm sure you'll have cobbled together some code
to automatically re-link the front end to the back end. Same code is he

http://www.mvps.org/access/tables/tbl0009.h

How much work all of the above steps are really depends on how you've done
things now. For example to use the MS access runtime, you have to build and
provide your own menu system and interface. Since in all of my applications
I've always hidden the built in access menus, then deployment using the
runtime for me was no extra work at all. However if you've not been hiding
the MS access interface in your example appcation, then you have to address
this issue, Especially if you plan to use the runtime. (and of course if you
hide most of the MS access interface, then new users who will not be
overwhelmed with all kinds of menu options and features that they really
don't need to use).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada