Time to move on...

I'm finally at the stage where I need to investigate other options. I have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or find
something that will convert the Acess app to another language such as VB .NET
or JAVA where we can have a thin client or where I can break the form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank you
in advance for your advice!

Per PeterM:
I'm finally at the stage where I need to investigate other options. I have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or find
something that will convert the Acess app to another language such as VB .NET
or JAVA where we can have a thin client or where I can break the form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank you
in advance for your advice!

Sounds like maybe the front end and back end are all in one .MDB and the people
in the field are downloading the whole enchilada. Have I got that part right?

If so, and based on your idea of doing something with VB.net, I'd guess that the
people in the field have some sort of connection to the company LAN/WAN.

If that's true, the quickest/easiest thing to try is separating the front end
from the back end (i.e. a .MDB for each...). Then the users only have to
download the front end once and they can be ODBC'd to the back end.

Depending on how that works out and how many users are going to be hammering on
it, the next thing I'd do is migrate the back to SQL Server and just change the
ODBC links in the front end to point to the server tables.

Once that is up and running, I'd look for performance issues and write stored
procedures in the back end to resolve them.
--
PeteCresswell

PeterM wrote:
I'm finally at the stage where I need to investigate other options.
I have consultants in the field all over North America and our Access
app is critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's becoming a major problem for people in the field to download a
thick client 2 or 3 times a week.

I either need a way to split up the application into smaller pieces
or find something that will convert the Acess app to another language
such as VB .NET or JAVA where we can have a thin client or where I
can break the form in the Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank you in advance for your advice!

Why do they have to download the MDE 2 or 3 times a week?


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

Actually, the 80 meg .mde is just the front end...we have our tables out on a
server provided by a host provider. The app has over 125 forms, 300 queries
and about 45 tables.

Actually we're a very small company and have only about 10 people in the
field accessing this app. They all have ODBC connections setup and that's
how they get to the tables. All they need is an ISP connection, usually in a
hotel or at home and the ODBC connection directs them to the back end tables.
We're restricted to MySQL on the host provider on the back end for now, but
ODBC handles it perfectly.

I'm an old COBOL developer years ago and have taught myself Access over the
past 3 years. So I don't look forward to learning another language and
developing another architecture, but it's looking more and more like I need
to do that.

Do you know of any decent conversion tools or have any other ideas? thanks
for your response Pete

"(PeteCresswell)" wrote:

Per PeterM:
I'm finally at the stage where I need to investigate other options. I have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or find
something that will convert the Acess app to another language such as VB .NET
or JAVA where we can have a thin client or where I can break the form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank you
in advance for your advice!

Sounds like maybe the front end and back end are all in one .MDB and the people
in the field are downloading the whole enchilada. Have I got that part right?

If so, and based on your idea of doing something with VB.net, I'd guess that the
people in the field have some sort of connection to the company LAN/WAN.

If that's true, the quickest/easiest thing to try is separating the front end
from the back end (i.e. a .MDB for each...). Then the users only have to
download the front end once and they can be ODBC'd to the back end.

Depending on how that works out and how many users are going to be hammering on
it, the next thing I'd do is migrate the back to SQL Server and just change the
ODBC links in the front end to point to the server tables.

Once that is up and running, I'd look for performance issues and write stored
procedures in the back end to resolve them.
--
PeteCresswell

Is your application split? It should be split into FrontEnd and
BackEnd unless you have compelling reasons for not splitting it.

I've done routines in Access to export data from related tables at a
source location and to import that data at the destination location.
That kind of thing allows you to transfer just the selected data.

How much new data is actually involved in each of your 3 transfers per
week? Couldn't be 80 meg.

If I might be of help, please decode my address and send me your
contact information.

HTH
--
-Larry-
--

"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options.
I have
consultants in the field all over North America and our Access app
is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces
or find
something that will convert the Acess app to another language such
as VB .NET
or JAVA where we can have a thin client or where I can break the
form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank you
in advance for your advice!

"PeterM" wrote in message
...
Actually, the 80 meg .mde is just the front end...we have our tables out
on a
server provided by a host provider. The app has over 125 forms, 300
queries
and about 45 tables.

So you're telling us that there are total changes to the front-end 2 or 3
times a week? I have 51 users and don't make that many front-end changes to
the 12 apps I support every week. OK, here are your solutions:

1. Create an ASP front-end
2. Use a Terminal Server, build a folder for each user and have him/her
connect to their own copy of the front-end on the Terminal Server.

The queries and tables should not be a factor, if they are, in fact, linked,
not local. 125 forms should not even approach 15 MB, unless they have
images.

3. Take out the images.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

Yes, pls see my response to Pete Cresswell. It's split into a .mde front end
for using forms, reports and queries and the tables are connected via ODBC to
a back end server. The 80 meg .mde contains just the forms, reports,
queries, modules, etc. It changes frequently for enhancement requests. It's
so large because it does our marketing, lead generation and reporting,
timesheet, expense report, invoicing, purchase orders, skills matrix,
pricebook, knowledgebase, customers, vendors, contacts, group calendar, etc.

Any help would be appreciated.

"Larry Daugherty" wrote:

Is your application split? It should be split into FrontEnd and
BackEnd unless you have compelling reasons for not splitting it.

I've done routines in Access to export data from related tables at a
source location and to import that data at the destination location.
That kind of thing allows you to transfer just the selected data.

How much new data is actually involved in each of your 3 transfers per
week? Couldn't be 80 meg.

If I might be of help, please decode my address and send me your
contact information.

HTH
--
-Larry-
--

"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options.
I have
consultants in the field all over North America and our Access app
is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces
or find
something that will convert the Acess app to another language such
as VB .NET
or JAVA where we can have a thin client or where I can break the
form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank you
in advance for your advice!

thanks for responding...please see me responses to Pete Creswell and Larry
Daugherty for an explanation. Any advice would be appreciated.

"Rick Brandt" wrote:

PeterM wrote:
I'm finally at the stage where I need to investigate other options.
I have consultants in the field all over North America and our Access
app is critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's becoming a major problem for people in the field to download a
thick client 2 or 3 times a week.

I either need a way to split up the application into smaller pieces
or find something that will convert the Acess app to another language
such as VB .NET or JAVA where we can have a thin client or where I
can break the form in the Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank you in advance for your advice!

Why do they have to download the MDE 2 or 3 times a week?


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

Hi Peter,

After posting my solution I saw the rest of the thread and see that it
solves a problem you don't have. Sorry about that.

I don't know of any viable conversion tools from Access to anything.
There is one outfit out there somewhere that promises conversion to
VB. I believe I tried it back when VB3 was the target. It failed
miserably. So, No.

I do have other ideas but they are only relevant in terms of your
business model and your application. Otherwise you're asking us to
answer your specific questions without a clue as to relevance.

What is your application? What is its domain? What problems does it
solve?

What's your business model. Why do you have people in the field?
How do they interact with your customer base?

What the bloomin' H... is going on that you need 3 changes to your
application each week?

With that degree of instability, why are you using an MDE? I know,
it's because you don't want someone to see your commented VBA. Who;
your field reps? Your customers? Both?

If the distrust ("trust but verify") is of your field reps, can they
be bonded ("trust but insure")? If so there are workable solutions
that involve their using MDB, converting to MDE, etc...

Diplomats find nice ways to candy coat things. A skill I never
learned: Take all of the following with a large grain of salt and the
belief that I really do intend to help.

YOU are the source of your problems! :-) You wrote the code that
swelled to that huge 80 meg.

You had the vision to see what could be and the drive to get things
done and sold and out there serving your customers. However, I'm
going to assume that you did a lot of work along the way that was done
in the quickest, simplest way you could and that you then Pressed On!
For example: I can't believe that your application actually requires
300 discrete and separate queries! Some of those have to be simple
variations on a theme and good candidates for collapsing into
parameterized queries. FWIW the query window on most of my
applications is empty. I embed most queries into their forms and
reports. 125 forms? mmm...maybe. In my ignorance of your application
I will still hazard a guess that the front end should be less than
half that size.

On your own you're unlikely to quickly recognize and resolve the
problems. Coming from the Cobol world you probably brought a lot of
Cobol thinking with you. In most instances that's good because most
of what you knew there is true in Access as well. However you
probably brought over and applied many things that shouldn't be
applied in Access but that worked. I don't know what those things
might be. I never danced Cobol. I've looked at some Cobol code at
the insistence of one of my mainframe buddies. I could follow it but
I never got into it.

If you carried forward the good things you should have been using in
the Cobol world then you documented things as you began; at least to
the point of Problem Statement, Product Specification and Functional
Specification. With 3 changes per week you may not have been able to
keep things current.

I recommend that you tweak the Specifications to reflect what's going
on now and to then look around for an Access expert. I don't mean
just someone who makes a living selling services using Access but a
consultant with many successful projects who is capable of quickly
mastering the business arena of your application.

Give her or him the updated specifications and a verbal walk through
of everything just as though you were hiring that person to replace
you as the Software Engineer on this project. Tell that person that
you would like them to become familiar with the specifications and to
then give you a preliminary design for an Access based product. Tell
them they have a week to get it done and that they have unrestricted
access to you. That means that when they're interacting with you the
phone doesn't ring and there will be no taps at the door. If they
really whine and cry give them two weeks - same conditions. They will
need particular help identifying the entities in play. Don't look at
their work until the agreed time is up.

At the end of the agreed upon time, look at their preliminary design.
If it's significantly different from yours, find out why.

Take everything said here with the idea that it's intended to help
you. I do believe you can find workable solutions while staying
within Access.

HTH
--
-Larry-
--

"PeterM" wrote in message
...
Actually, the 80 meg .mde is just the front end...we have our tables
out on a
server provided by a host provider. The app has over 125 forms, 300
queries
and about 45 tables.

Actually we're a very small company and have only about 10 people in
the
field accessing this app. They all have ODBC connections setup and
that's
how they get to the tables. All they need is an ISP connection,
usually in a
hotel or at home and the ODBC connection directs them to the back
end tables.
We're restricted to MySQL on the host provider on the back end for
now, but
ODBC handles it perfectly.

I'm an old COBOL developer years ago and have taught myself Access
over the
past 3 years. So I don't look forward to learning another language
and
developing another architecture, but it's looking more and more like
I need
to do that.

Do you know of any decent conversion tools or have any other ideas?
thanks
for your response Pete

"(PeteCresswell)" wrote:

Per PeterM:
I'm finally at the stage where I need to investigate other
options. I have
consultants in the field all over North America and our Access
app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80
meg. It's
becoming a major problem for people in the field to download a
thick client 2
or 3 times a week.

I either need a way to split up the application into smaller
pieces or find
something that will convert the Acess app to another language
such as VB .NET
or JAVA where we can have a thin client or where I can break the
form in the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank you
in advance for your advice!

Sounds like maybe the front end and back end are all in one .MDB
and the people
in the field are downloading the whole enchilada. Have I got that
part right?

If so, and based on your idea of doing something with VB.net, I'd
guess that the
people in the field have some sort of connection to the company
LAN/WAN.

If that's true, the quickest/easiest thing to try is separating
the front end
from the back end (i.e. a .MDB for each...). Then the users only
have to
download the front end once and they can be ODBC'd to the back
end.

Depending on how that works out and how many users are going to be
hammering on
it, the next thing I'd do is migrate the back to SQL Server and
just change the
ODBC links in the front end to point to the server tables.

Once that is up and running, I'd look for performance issues and
write stored
procedures in the back end to resolve them.
--
PeteCresswell

Our application is about that big (80). Zipped, it is about
12 meg. Compressed to self extracting executable with rar,
then zipped, it is about 10.

The application has a shell mdb/mde, 4-12 application
mde's at 1-10MB, and a library mde at 10MB.

Each application module references the library mde
(tools, references).

The shell references all of the application modules
and the library module.

For ease of installation and support, we require all
clients to install to the specified program files
folder.

When using the shell as an mdb, we can replace any
application mde, provided the library mde does not
change.

If you use application mdb modules, then you could
also update the library module without changing all
application modules.

Or you might not have enough shared code to justify
a library module.

We also have code in DLL's: these may be updated
independently of the mde's.

Within the application modules, some forms call other
forms. From the shell, application modules are called
from the menu system.

(david)


"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options. I
have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or
find
something that will convert the Acess app to another language such as VB
.NET
or JAVA where we can have a thin client or where I can break the form in
the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank
you
in advance for your advice!