Re: Split out reports in a FE into its own DB?

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Marshall Barton (marshbarton_at_wowway.com)
Date: 02/16/05 

Date: Wed, 16 Feb 2005 09:01:09 -0600

As I said before, in the situation I was dealing with, I
didn't think it was worth it. However, your situation
and/or your criteria of what it's worth is probably
different then mine, so there's no definitive answer.

I suggest that you pick your most difficult report (in terms
of its need for form controls, global variables and tricky
record source query and see what it takes to move it to a
separate mdb. Once you get a feel for that, you'll get a
better idea if you want to proceed with all your other
reports or not. 

-- 
Marsh
MVP [MS Access]
Rick Roberts wrote:
>Thanks for your response and I appreciate your feedback. I have spent  some  
>time looking into this and I am still split on separating it out or not.  
>Part of me feels like it’s a good idea, part of me doesn't.
>
>Given your expertise what would you do?
>
> 
>> I haven't tried this kind of thing in a long time, because I
>> didn't think it was worth it.  However, I did get that
>> arrangement to work by referencing the reports mdb as a
>> library in the main front end mdb.  Then you can create a
>> public function in the reports mdb that can open the
>> reports.  The function wouldn't have to do anything beyond
>> passing arguments to the OpenReport method and some error
>> handling.  The main report's code would only need a minor
>> change.  E.g. instead of
>> 	DoCmd.OpenReport . . .
>> you would use:
>> 	MyOpenReport . . .
>> 
>> Some things the reports mdb must do is link to all the
>> tables the same way the main mdb does and contain all the
>> queries needed by the reports.
>> 
>> One big drawback is that the reports will not be able to
>> refer back to values in the main mdb.  So if you do that
>> sort of thing, you will have to do some rework to get the
>> values to the reports.
>> 
>> It would have been nice if Access provided an Open method
>> for a form/report Document or AccessObject, but until it
>> does, AFAIK, OpenReport is the only way to open a
>> form/report using arguments such as View and WhereCondition.

Relevant Pages

  • Re: why>?
    ... MDB are a useful learning tool ... I used them for several years before moving to SQL. ... We've got the most exciting pivotTables anywhere. ... it's each to share reports with others; copy reports; duplicate ...
    (microsoft.public.excel)
  • RE: Best way to protect a shared MSAccess database...
    ... Besides the .mdb file permissions itself, ... puts all of the data into one .mdb and all of the forms, reports, querys, etc ... Database Utilities to compact current.mdb (this reclaims the file space ... Startup and uncheck the Allow Full Menus option. ...
    (microsoft.public.windows.server.sbs)
  • Re: A2007 ADPs
    ... With your comment about MDB and crosstab reports against a SQL-Server, ... are hitting one of the main point of using passthrough queries. ... Please convince me that Linked Tables work as well as an ADP. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Automatically bypass security warning "enable this content"
    ... must be come across the network when working with forms and reports that are ... run from an MDB or ACCDB file that sits on the LAN. ... location" on the users computer. ...
    (microsoft.public.access.modulesdaovba)
  • Deployment for non-admin use - best practices
    ... We have a large access application (>100MB mdb with forms and reports, ... installer that installed your application to C:\Program ... is ugly from a security point-of-view and is ugly ...
    (microsoft.public.access.modulesdaovba)