FE/BE -- Tables but not reports ?

[jfp]

I understand the concept of splitting app into local FE and remote
(server) BE where the tables are on the back end. It seems as though
Access forces this splitting to be limited to tables, and it is not
clear that this makes complete sense.
The normal idea is something like this:
Developer makes forms/reports and packages as a FE database. Primary
user maintains data in tables on BE. Auxiliary users perhaps modify
data or perhaps only run reports etc. All is great at first. NOW --
the primary user decides to change one of the reports (perhaps even
something as trivial as changing a title). This necessitates a
repackaging and redistribution of the entire front end app to ALL users.
In contrast, if the report could be on the back-end, the primary user
(or developer) would simply change it there and all users would
immediately have the new version. A logical extension would be to have
most (or, perhaps even all, including the opening one (?)) forms on the
back-end. This does not appear to be possible, since there is only a
"Link Tables" menu choice.

Comments ?

 

[Albert D. Kallal]

Of course the problem here is that you are suggesting that users actually
develop and modify the reports after you distribute them, are you?

Your development process of software needs to be separated from your users.
You new reports, or changes need to be very carefully test and re-tested.
Once the changes are good, then yes, you should re-distribute the new
application front end to each user. Further more, you should be distributing
a mde file. Further then that, you most certainly do hide the ms-access
interface, so that users don't make changes and mess around with the
application.

if you have a good software development process, then the above will be the
result.

As for users needing to make new reports, you generally only need to provide
the users with some screens to "select" the options they need for the
report. I mean a sales report only needs a date range, and perhaps what
samples name (or a "all" option). If you design your application correctly,
then your users SHOULD NOT need to design any reports I have applications
with more then 160 forms, and in use by a fairly large user base. That means
an application with a LOT of options. Not one of the users has asked for a
new report in more than 1 year.

For some screen shots of those report screens you can take a look at:

http://www.attcanada.net/~kallal.msn/ridesrpt/ridesrpt.html

The above will give your some ideas. I don't want to sound to hash here, but
I don't believe in allowing the users to see the ms-access interface, nor
*should* they need to modify reports. If the users have to modify the
reports, then the user requirements were not determined correctly in the
first place.

If you take the idea that your users should not be modify the application,
then the split problem goes away. You can clearly use some code to
automatically update each persons front end, and that is encouraged. Tony
has one such free utility at:

http://www.granite.ab.ca/access/autofe.htm

 

[Bruce M. Thompson]

The normal idea is something like this:

Developer makes forms/reports and packages as a FE database. Primary
user maintains data in tables on BE. Auxiliary users perhaps modify
data or perhaps only run reports etc. All is great at first. NOW --
the primary user decides to change one of the reports (perhaps even
something as trivial as changing a title). This necessitates a
repackaging and redistribution of the entire front end app to ALL users.

This really only *requires* placing the modified front end file in a central
location. The distribution could be automated either through a vbscript file in
each workstation's "Startup" folder to always copy a fresh version of that
front-end file to their machine each time they boot up or, if the update is
needed sooner than that, a utility for managing and updating client machines,
such as Tony Toews' Auto FE Updater (http://www.granite.ab.ca/access/autofe.htm)
which will check, each time the user goes to start the application, to see if an
update is available and copy the update to their machine.

In contrast, if the report could be on the back-end, the primary user
(or developer) would simply change it there and all users would
immediately have the new version. A logical extension would be to have
most (or, perhaps even all, including the opening one (?)) forms on the
back-end. This does not appear to be possible, since there is only a
"Link Tables" menu choice.

Since Access versions 2000, and later, prohibit making design changes while
other users are accessing the files, this could not work. A split file isn't a
split file if you move everything back into the back-end file. Anyway, it
doesn't make sense to be mucking around with your data file just to modify a
report.

 

[Douglas J. Steele]

Another possibility is to have an application MDE, but also a user-specific
"report" MDB, where they can develop their own reports if they want.

 

[Albert D. Kallal]

Another possibility is to have an application MDE, but also a user-specific
"report" MDB, where they can develop their own reports if they want.

Yes, that is a excellent workaround Doung. It is a idea I will suggest in
future for this kinds of situations...

 

[Douglas J. Steele]

Yes, that is a excellent workaround Doung. It is a idea I will suggest in
future for this kinds of situations...

It has the advantage, too, that since the reporting is done in an MDB, you
can open the reports in design mode in your code, and make changes that you
can't make in an MDE.

 

[jfp]

well -- in this case, my customer is the primary user.
HE has the complete functional Access and uses it himself for "simple
stuff" and calls me in for the more difficult stuff. On this current
go-round, he gave me (10) reports (with queries) he developed for
various business needs and asked me to package it all together so that
OTHER people in his office could generate the reports without asking him
to do it for them. I can clearly see that he is going to come up with
report 11, 12, etc. and eventually get annoyed if he has to call me
everytime he wishes to add a new one.
Of course, i would love a customer with a budget big enough to have me
do everything -- and, a few years ago, when the economy was good, that
was what i had. But, today things are different -- this customer is
also different, he tends to try to do things himself.

Hope that explains this admittedly unusual situation.
-=-=-=

 

[jfp]

It has the advantage, too, that since the reporting is done in an MDB, you
can open the reports in design mode in your code, and make changes that you
can't make in an MDE.

Could you please expound on this idea ?
See my post of a few minutes ago explaining the particulars of this
situation. What i would like is:
1) i develop the framework for the system,
2) my customer (primary user) has access to the reports so that he can
make simple changes to them,
3) other users go through my application (via ODE runtime) and use the
reports.

Thanks !

 

[Douglas J. Steele]

Could you please expound on this idea ?
See my post of a few minutes ago explaining the particulars of this
situation. What i would like is:
1) i develop the framework for the system,
2) my customer (primary user) has access to the reports so that he can
make simple changes to them,
3) other users go through my application (via ODE runtime) and use the
reports.

Given the scenario you described, just put the reports in an MDB of their
own, and distribute it.

You can use Automation to open the reports.

ACC: How to Use Automation to Print Microsoft Access Reports:
http://support.microsoft.com/default.aspx?scid=kb;[LN];145707
ACC2000: How to Use Automation to Print Microsoft Access Reports
http://support.microsoft.com/default.aspx?scid=kb;[LN];210132
ACC2002: How to Use Automation to Print Microsoft Access Reports (Q296586)
http://support.microsoft.com/default.aspx?scid=kb;[LN];296586
ACC: Using Microsoft Access as an Automation Server (Q147816)
http://support.microsoft.com/default.aspx?scid=kb;[LN];147816
ACC2000: Using Microsoft Access as an Automation Server (Q210111)
http://support.microsoft.com/default.aspx?scid=kb;[LN];210111