Re: too many modules
- From: SteveM <sbmack7@xxxxxxxxx>
- Date: Thu, 28 May 2009 18:03:20 -0700 (PDT)
On May 28, 4:06 pm, Jack Leach <dymondjack at hot mail dot com> wrote:
At this point one might also consider some different applications aside from
access. Crystal Reports may be an option to pull a large amount of reports
out of access, thus freeing space. And possibily some standalone .net forms
which can connect to the backend(s) as datasources (express version are free
and should be able to handle this without too much difficulty if I'm somewhat
on track).
--
Jack Leachwww.tristatemachine.com
"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
"John Spencer" wrote:
One option I have used is to create two databases.
One database is used for all the input, etc. with a few key reports in it.
The second has all the reporting capabilities in it.
The users just keep both open if they are using both frequently.
'====================================================
John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
'====================================================
Jack Leach wrote:
IMVHO, I would make this a priority as soon as you get the immediate
situation taken care of, just to avoid another catastrophe in the future.
Databases always seem to grow, and whatever means you come up with to handle
the immediate task is probably not going to be ideal as far as db designs go,
and you can almost count on it growing further in the future (after all, this
is why you're here now right??).
I don't mean to sound like a business consultant here, but this type of
splitting FE's and organizing might be the only *real* answer for the long
term. Understandably, this is a huge project, but 100hours to take care of
it this year (possibly redirecting some user's tasks to accomplish it) may
put you in a position will you will never have to worry about an oversized db
again.
As for duplicate code, if it's just copy&paste from one FE to the next, a
sound documentation system should make this easy enough to track and update
in batch form when the time comes. Or possibly a reference library as
earlier mentioned.
Anyway, this is just my personal opinion... don't take it the wrong way. I
just hate to see someone spend so much time on what will probably be a only a
relatively temporary solution. And I would expect performance levels to
significantly increase if you could quarter the amount of objects through a
project like that. There seems to be so much going on, and the suggestions
so far will add to the internal work required by access to process the same
data, where as this type of long term solution would probably decrease it
from where you are now.
One thing I learned long ago and far away was to step back
occasionally and distinguish between a modeling problem and a
consulting problem. Some of the guys on this thread have cracked open
that door implicitly. It may be time to sit down with all of the
stakeholders associated with the product and have a "consulting"
rather than "programming" meeting.
I.e., step back, look at the bigger picture of business objectives,
and then align the efforts with objectives (quantitative, qualitative
and meta) that have been prioritized. Based on that, a mixed solution
may fall out that transcends managing 1000+ modules.
I'm only saying this because I've had sublime and often painful
opportunities to muddle through many technical messes that turned out
to be more about business process flaws rather programming.
Good luck though,
SteveM
.
- References:
- too many modules
- From: jWhytis
- Re: too many modules
- From: Marshall Barton
- Re: too many modules
- From: jWhytis
- Re: too many modules
- From: Graham Mandeno
- Re: too many modules
- From: jWhytis
- Re: too many modules
- From: JimBurke via AccessMonster.com
- Re: too many modules
- From: jWhytis
- Re: too many modules
- From: Jack Leach
- Re: too many modules
- From: jWhytis
- Re: too many modules
- From: Jack Leach
- Re: too many modules
- From: John Spencer
- Re: too many modules
- From: Jack Leach
- too many modules
- Prev by Date: Automate linking of document via OLE
- Next by Date: Re: too many modules
- Previous by thread: Re: too many modules
- Next by thread: Please help! Can't see Project Explorer
- Index(es):
Relevant Pages
|
Loading