Re: Access Size Problem
From: Andreas (nobody_at_home.com)
Date: 03/22/05
- Next message: Andreas: "Re: Application Exit Event"
- Previous message: Charles Tam: "Application Exit Event"
- In reply to: Andreas: "Re: Access Size Problem"
- Next in thread: Albert D. Kallal: "Re: Access Size Problem"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 22 Mar 2005 22:46:25 +1200
Update:
1)
You could create the following structure:
Master - linking to Child1, Child2, Child3, Common
Child1 - linking to Common
Child2 - linking to Common
Child3 - linking to Common
Common
This way, all your common "stuff" is available to the Master and all
children. Master becomes an interface to your different groups of
functionality (essentially a menu). You could even move groups of
non-interlinked tables into the children (if you are linking).
2)
It appears (in XP) you can even edit the code of all the databases from
the Master - cool, even if a little confusing at first. Have not tried
the forms/reports.
Regards,
Andreas
Andreas wrote:
> Hi,
>
> I never said it would be easy :-)
> I have only done this once, a long time ago.
> It took me a while to get it working just right.
>
> The idea is, that you put everything that belongs to a particular group
> of functionality into a seperate database. To "design" any of the
> objects in the "child", you have to open that database.
>
> Then you use the master to "execute" the functionality provided by the
> child (Public Subs, Public Functions, Forms). This should be designed in
> such a manner, that a child does not need to talk to another child. When
> the "child" finishes, it returns to the master.
>
> Without setting up a sample, I can't give any more advice.
> But it all comes down to careful planning and lots of testing "stuff".
> Considering the size of your application, and the problems you are
> getting, may be the extra effort is worth it just for the sake of a good
> organisational structure (a bit like proper normalization of tables).
> I am sure there would also be plenty of proponents re moving to .Net.
> Now there is a thought: Redo the entire application :-) Oh joy :-)
>
> Regards,
> Andreas
>
>
> Roy Goldhammer wrote:
>
>> Thankes Andreas
>>
>> So the split is the referance i'm talking about.
>>
>> I don't know what are the aspects of the spliting.
>>
>> From the master MDB i can see the other moduls of the child mdb's. But i
>> can't reach them by opening them
>>
>> The only reach to the child MDB's by building functions on the child
>> MDB and
>> run them on the master by using Call
>>
>> After i'm on the child i can't use any funcion in the modules of the
>> Master
>> mdb. But i can use its forms. and that was the only way i could go
>> back to
>> the master for opening other child
>>
>> It looks very complecated and i only asking one question: is there a
>> simple
>> way to do this?
>>
>>
>> "Andreas" <nobody@home.com> wrote in message
>> news:e9#gEdrLFHA.2748@TK2MSFTNGP09.phx.gbl...
>>
>>> Well, I do not work on anything this size.
>>> May be I shouldn't say anything.
>>> I hate the "red face" scenario :-)
>>>
>>> 1) I am not sure what you mean re:
>>> The import and export of objects are failed in some times.
>>>
>>> 2) I would probably try to "split" the frontend (even so I don't know
>>> what effect this may have on SourceSafe). Surely there are several
>>> distinct aspects to the database. Set them up as seperate mdb's (mde's)
>>> and then link them into the master (in VBA, Tools.References). Possibly
>>> a slight performance hit but much easier to manage.
>>>
>>> Regards,
>>> Andreas
>>>
>>>
>>> Roy Goldhammer wrote:
>>>
>>>> Thankes Albert
>>>>
>>>> The size of my mdb is even double 15 more then your database. And i do
>>
>>
>> have
>>
>>>> almost 1000 forms and reports.
>>>>
>>>> the 180Mb is after compact.
>>>>
>>>> I've asked many times here before about using refarances in access and
>>>> nobody answer about it
>>>>
>>>> Do you know about it something?
>>>>
>>>> "Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in message
>>>> news:uqItGWkLFHA.4092@tk2msftngp13.phx.gbl...
>>>>
>>>>
>>>>> Obviously, as you work during the day, you will frequently compact
>>>>> your
>>>>> database.
>>>>>
>>>>> What is the size of your database after you do compact?
>>>>>
>>>>> (further, you don't have a bunch of screen background graphics etc
>>
>>
>> thrown
>>
>>>> in
>>>>
>>>>
>>>>> there..do you?).
>>>>>
>>>>> To give you an idea, here is a small application of mine, the numbers
>>
>>
>> are:
>>
>>>>> lines of code in Modules = 8654
>>>>> Lines of code in forms = 16654
>>>>> Lines of code in reports = 2385
>>>>> ------------------
>>>>> total lines of code = 27693
>>>>>
>>>>> number of Forms = 163
>>>>> number of Reports = 77
>>>>> number of tables (total) = 63
>>>>> number of tables (user) = 54
>>>>> number of modules = 23
>>>>> number of Queries = 187
>>>>>
>>>>> The whole above application is LESS then 10 megs in size. And, for use
>>
>>
>> by
>>
>>>>> users, after converting to mde, the size is only 6 megs.
>>>>>
>>>>> So, when you talk about 180 megs in size, either somting is
>>>>> wrong!!..or
>>
>>
>> it
>>
>>>>> is big! So, do you numbers work abou to be about 20 times more then
>>>>> what
>>
>>
>> I
>>
>>>>> got above (ie: in place of 162 forms, you would have 1000+ forms to
>>>>> get
>>>>> somting in the 180 meg size).
>>>>>
>>>>> --
>>>>> Albert D. Kallal (Access MVP)
>>>>> Edmonton, Alberta Canada
>>>>> pleaseNOOSpamKallal@msn.com
>>>>> http://www.members.shaw.ca/AlbertKallal
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>
- Next message: Andreas: "Re: Application Exit Event"
- Previous message: Charles Tam: "Application Exit Event"
- In reply to: Andreas: "Re: Access Size Problem"
- Next in thread: Albert D. Kallal: "Re: Access Size Problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
