updating people's FE by sending them the recently modified objects

[WindAndWaves]

Hi Gurus

I have been working on a rather sophisticated update procedure for FEs of my
application that are spread throughout the country.

Now, I recently thought: WHAT IF

I identify all the objects in the database (may it be tables, queries,
forms, etc.....ie. NOT BE tables) that have been changed recently.

Then : place those in an update MDB

Send the customers this update MDB and let the MDB overwrite/copy these
objects into their Front end

This system would be much better than setting them a whole new FE, because:
a. FE is huge (>50 megabyte)
b. No need to recustomise people's Front End or relink existing tables

Has anyone ever deployed this method and if so, what was the outcome????

TIA

- Nicolaas

[MacDermott]

I did this successfully in Access 97 on Windows 98, but when my client moved
to Access 2000 on Win2K, it became problematic. The need didn't persist, so
neither did I.

Comments:
This takes a LOT more programming.
What all have you got in 50 MB of front end? A lot of graphics? (Maybe
you could store these in separate files and relink?) Perhaps you could
break up the front end, keeping some of it in library files?

HTH
- Turtle

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:Xh******************@news.xtra.co.nz...

Hi Gurus

I have been working on a rather sophisticated update procedure for FEs of my application that are spread throughout the country.

Now, I recently thought: WHAT IF

I identify all the objects in the database (may it be tables, queries,
forms, etc.....ie. NOT BE tables) that have been changed recently.

Then : place those in an update MDB

Send the customers this update MDB and let the MDB overwrite/copy these
objects into their Front end

This system would be much better than setting them a whole new FE, because: a. FE is huge (>50 megabyte)
b. No need to recustomise people's Front End or relink existing tables

Has anyone ever deployed this method and if so, what was the outcome????

TIA

- Nicolaas

[Larry Linson]

I did something similar in Access 2.0 and it worked nicely. It's the same
functionality that was used by the third party source code control products
of the day.

It didn't work in Access 95, because there was one type of import you
couldn't do and one type of export. The third party source control authors
got into some other aspect of the business about then, though the bugs were
fixed in Access 97 and later.

What do you have in that Front End? I don't think, in any version, I've
ever come close to an 80MB front end -- are you including the runtime
support in that figure? If so, you don't have to redistribute it unless
you've added functionality that requires additional OCXs, etc. You might
take a look at reducing your use of pictures as background, etc., which can
pump up the size a lot.

I won't even insult you by asking if you are conscientious to Compact the FE
on a regular basis. They grow like topsy during development as you modify,
delete, and add objects.

Have you taken a look at Tony Toews' FrontEndUpdater at his site,
http://www.granite.ab.ca/accsmstr.htm? It may do what you need.

But, since the days of Access 2.0, I've just made available the whole front
end for download from the server.

Larry Linson
Microsoft Access MVP

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:Xh******************@news.xtra.co.nz...

Hi Gurus

I have been working on a rather sophisticated update procedure for FEs of my application that are spread throughout the country.

Now, I recently thought: WHAT IF

I identify all the objects in the database (may it be tables, queries,
forms, etc.....ie. NOT BE tables) that have been changed recently.

Then : place those in an update MDB

Send the customers this update MDB and let the MDB overwrite/copy these
objects into their Front end

This system would be much better than setting them a whole new FE, because: a. FE is huge (>50 megabyte)
b. No need to recustomise people's Front End or relink existing tables

Has anyone ever deployed this method and if so, what was the outcome????

TIA

- Nicolaas

[WindAndWaves]

let me answer a few questions:

a. my FE does not have a single picture embedded.

b. my FE used to be around the 30 megabytes, but it all of a sudden became a
lot bigger (around the 60 megabytes)

c. I have a different post about databases growing like cabbages. I will
probably have to import the objects into a new database.

Anyway, it sounds like the concept might work. Great. The main worry that
I have is that, for some reason or other, too many or too few objects are
recognised as having been changed.

For example, if you change all the forms with a function like
for each form in dbs.forms (not the correct syntax - but I am sure you
will get the idea)
.............
next form

I was keen to hear your experiences, which sound positive, before embarking
on the project.

The import function will work perfect I am sure.

- Nicolaas

[david epsom dot com dot au]

I'm familiar with an A97 application that does this: it is working
without any problems. We don't do this for our major products
because it doesn't work with an MDE.

If you are using a secured database, you will also have to build
code to handle developer log in, and automating the application
of permissions effectively forces you to use group permissions
rather than individual permissions.

(david)
"WindAndWaves" <ac****@ngaru.com> wrote in message
news:Xh******************@news.xtra.co.nz...

Hi Gurus

I have been working on a rather sophisticated update procedure for FEs of my application that are spread throughout the country.

Now, I recently thought: WHAT IF

I identify all the objects in the database (may it be tables, queries,
forms, etc.....ie. NOT BE tables) that have been changed recently.

Then : place those in an update MDB

Send the customers this update MDB and let the MDB overwrite/copy these
objects into their Front end

This system would be much better than setting them a whole new FE, because: a. FE is huge (>50 megabyte)
b. No need to recustomise people's Front End or relink existing tables

Has anyone ever deployed this method and if so, what was the outcome????

TIA

- Nicolaas

[Trevor Best]

WindAndWaves wrote:

Hi Gurus

I have been working on a rather sophisticated update procedure for FEs of my
application that are spread throughout the country.

Now, I recently thought: WHAT IF

I identify all the objects in the database (may it be tables, queries,
forms, etc.....ie. NOT BE tables) that have been changed recently.

Then : place those in an update MDB

Send the customers this update MDB and let the MDB overwrite/copy these
objects into their Front end

This system would be much better than setting them a whole new FE, because:
a. FE is huge (>50 megabyte)
b. No need to recustomise people's Front End or relink existing tables

Has anyone ever deployed this method and if so, what was the outcome????

TIA

- Nicolaas

The way I do it is to send the entire MDB (mainly because it's a renamed
MDE <g>). I have a program that I wrote for this purpose called DbStart,
it looks into a table called tblProfile to get a code version number. IF
the one on the network is greater then it copies that down to the C:
drive (or specified path) and starts it, during this process the
original is backed up and then other profiles from arforementioned table
are copied in so user's own preferences are preserved. It also
identifies the version of Access that created the application and runs
the correct version.

As for size, the FE is generally 32MB but the size doesn't matter much,
the client with the worst (slowest) connection to me has Winzip9 so I
can utilise the enhanced deflate within that to save a meg or two. It
zips down to about 5-7MB.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Lyle Fairfield]

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

<snips>

the FE is generally 32MB

<snips>

This astounds me. Could you, please, describe this front end, somehow
explaining its size?

--
Lyle
(for e-mail refer to http://ffdba.com/)

[Trevor Best]

Lyle Fairfield wrote:

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

<snips>

the FE is generally 32MB

<snips>

This astounds me. Could you, please, describe this front end, somehow
explaining its size?

550+ tables
400+ forms
1300+ queries
100+ reports

Procurement and Materials Management system for engineering,
construction mainly in the oil and gas industry, for procurement it's
cradle to grave with:

MTO (consolidation into) Requisition (+revisions), enquiry (RFQ & ITT),
bid analasys and comparison (Commercial & Technical), purchase order
(+amendment orders), expediting, shipping, goods receiving (including
OS&D), inventory*, material issue, returns, work plan (soft and hard
allocation of materials). Engineering document control, Vendor document
control, engineering document work package scheduling, procurement
scheduling and planning, activity tracking. Lookup and support tables,
e.g. terms and conditions for output formats (Order & Enquiry), supplier
database with product codes, accreditations, QA, etc.

Many interfaces into other systems including ERP/Accounts (SAP, CODA,
etc), CAD (for MTOs) and other packages of the same ilk (for
subcontracting, etc). There are some blobs in it, for logos, etc but
they wouldn't account for much size.

I've probably missed a few features going off the top of my head but you
can see it's not your average inventory control system or something,
it's used to build things like oil rigs, refineries, processing plants,
water treatment plants, it's even been used for small projects like
building rollercoasters and other such rides.

*strangely enough, the inventory doesn't account for any tables as it's
not a physical entity as such, it's a product of goods received vs
issued vs returned. Some of that table count will consist of SQL Server
views though.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Lyle Fairfield]

Trevor Best <nospam@localhost> wrote in news:40d08200$0$29553$afc38c87
@auth.uk.news.easynet.net:

Lyle Fairfield wrote:

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

<snips>

the FE is generally 32MB

<snips>

This astounds me. Could you, please, describe this front end, somehow
explaining its size?

550+ tables
400+ forms
1300+ queries
100+ reports

Procurement and Materials Management system for engineering,
construction mainly in the oil and gas industry, for procurement it's
cradle to grave with:

MTO (consolidation into) Requisition (+revisions), enquiry (RFQ & ITT),
bid analasys and comparison (Commercial & Technical), purchase order
(+amendment orders), expediting, shipping, goods receiving (including
OS&D), inventory*, material issue, returns, work plan (soft and hard
allocation of materials). Engineering document control, Vendor document
control, engineering document work package scheduling, procurement
scheduling and planning, activity tracking. Lookup and support tables,
e.g. terms and conditions for output formats (Order & Enquiry), supplier
database with product codes, accreditations, QA, etc.

Many interfaces into other systems including ERP/Accounts (SAP, CODA,
etc), CAD (for MTOs) and other packages of the same ilk (for
subcontracting, etc). There are some blobs in it, for logos, etc but
they wouldn't account for much size.

I've probably missed a few features going off the top of my head but you
can see it's not your average inventory control system or something,
it's used to build things like oil rigs, refineries, processing plants,
water treatment plants, it's even been used for small projects like
building rollercoasters and other such rides.

*strangely enough, the inventory doesn't account for any tables as it's
not a physical entity as such, it's a product of goods received vs
issued vs returned. Some of that table count will consist of SQL Server
views though.

Sounds scarey, or humbling or something like that. Can you confirm the 550
tables in the front end?
I am looking at an adp here with roughly 10% of each object you name ...
44 forms, 10 reports, 17 quire samll modules, 145 sprocs udfs and functions
.... the latter are not in the fe of course and no tables in the fe (38 on
the server) either of course, and it's hovering around 1.2 megs.

--
Lyle
(for e-mail refer to http://ffdba.com/)

[WindAndWaves]

I have a database for small businesses with the following amounts:

Not necessarily a strength to have some many objects...

It all amounts to 65 megabytes..... And during a recent, involved,
computation, it grew to 1.3 gig, hence my post on growing like cabbages. I
still really like to know how to manage my size/how to prevent this type of
growth.

Cheers

Nicolaas

D-TYP_COUNT D CountOfType
AccessLayout 3
Administration 1
Forms 567
Macros 2
Main Groups (e.g. tables, forms, etc...) 9
Modules 131
MSysDb 1
Other 17
Queries 1393
Reports 78
Tables (linked) 107
Tables (not linked) 155

[Trevor Best]

Lyle Fairfield wrote:

Sounds scarey, or humbling or something like that. Can you confirm the 550 tables in the front end?
I am looking at an adp here with roughly 10% of each object you name ...
44 forms, 10 reports, 17 quire samll modules, 145 sprocs udfs and functions
.... the latter are not in the fe of course and no tables in the fe (38 on
the server) either of course, and it's hovering around 1.2 megs.

about 100 local, for some reason (I can't remember) I have a table of
4500 Access error messages. The one that would take a bit of room
contains details on each form, a kind of profile table where records
would look like:

FormName Setting Value
fpopMTOArea Caption Area (for %MTO%)
fpopMTOArea PrimaryKey MTOAreaID
fpopMTOArea QFFieldList MTOAreaID, Area
fpopMTOArea QFOrderBy Area
fpopMTOArea QfSearch Area
fpopMTOArea QfTable tblMTOArea
fpopMTOArea RestrictorPrefix ProjectID=CurrentProjectID()
fpopMTOArea RestrictorSuffix
fpopMTOArea Table tblMTOArea
fpopMTOArea Title Area (for %MTO%)

This is for generic functions to do things with forms.

Although if I export this to a CSV it takes 64K. There's probably around
150,000 lines of code in the app as well, which I'm trying to cut down
by use of triggers and stored procedures.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Alex]

I have a large Access application but I have broken the front end into
about 50 seperate FEs with a control panel to launch the appropriate
one. This means that each FE is relatively small 1-4 mB and the user
is only loading the functionality they need at any time. Of course
more than one FE can be loaded if necessary at any one time. This also
keeps the RAM requirements down and makes the updating easier since
often the update only effects a few of the FE files.
From the users point of view it works ad though it is a single
application.
Alex

[WindAndWaves]

that is a nice idea alex. Not sure if it would work for me, but that is
certainly a nice concept.

[Trevor Best]

WindAndWaves wrote:

that is a nice idea alex. Not sure if it would work for me, but that is
certainly a nice concept.

It also alows updating of specific componants if they are MDEs as well.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Tony Toews]

Trevor Best <nospam@localhost> wrote:

the FE is generally 32MB

550+ tables
400+ forms
1300+ queries
100+ reports

Sounds about right. I have an A97 FE that is about 24 Mb in size but its only got
150 tables, 1400 queries, 450 forms and 350 reports.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm