[AccessD] Friday: Access 2003 Help

Jürgen Welz jwelz at hotmail.com
Fri Jan 27 11:00:53 CST 2006


>From the Access 2003 help topic:  Tips for improving the performance of 
Microsoft Access and your system.

'Increase RAM on your computer. 40 MB of memory is recommended— 32 MB of 
memory plus an additional 8 MB of memory for Microsoft Access.'

I'll get right on that one...


Ciao
Jürgen Welz
Edmonton, Alberta
jwelz at hotmail.com





>From: Jürgen Welz <jwelz at hotmail.com>
>Reply-To: Access Developers discussion and problem 
>solving<accessd at databaseadvisors.com>
>To: "Access Developers discussion and problem 
>solving"<accessd at databaseadvisors.com>
>Subject: Re: [AccessD] Same form, different actions
>Date: Thu, 26 Jan 2006 14:24:04 -0700
>MIME-Version: 1.0
>X-Originating-IP: [65.54.168.200]
>X-Originating-Email: [jwelz at hotmail.com]
>Received: from databaseadvisors.com ([209.135.140.44]) by 
>bay0-mc2-f7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 
>Jan 2006 13:25:16 -0800
>Received: from databaseadvisors.com (databaseadvisors.com 
>[209.135.140.44])by databaseadvisors.com (8.11.6/8.11.6) with ESMTP id 
>k0QLO5128567;Thu, 26 Jan 2006 15:24:05 -0600
>Received: from omc2-s28.bay6.hotmail.com 
>(omc2-s28.bay6.hotmail.com[65.54.249.38])by databaseadvisors.com 
>(8.11.6/8.11.6) with ESMTP id k0QLO3128556for 
><accessd at databaseadvisors.com>; Thu, 26 Jan 2006 15:24:03 -0600
>Received: from BAY113-W2 ([65.54.168.102]) by omc2-s28.bay6.hotmail.com 
>withMicrosoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 13:24:04 -0800
>X-Message-Info: LGjzam7y+LtmkF+qp9XD5nYIrt8y5mxH9Xzqiqe+GtI=
>X-OriginalArrivalTime: 26 Jan 2006 21:24:04.0719 
>(UTC)FILETIME=[D57827F0:01C622BE]
>X-Content-Filtered-By: Mailman/MimeDel 2.1.7-SiteWide-HeaderFooter
>X-BeenThere: accessd at databaseadvisors.com
>X-Mailman-Version: 2.1.7-SiteWide-HeaderFooter
>Precedence: list
>List-Id: Access Developers discussion and problem 
>solving<accessd.databaseadvisors.com>
>List-Unsubscribe: 
><http://databaseadvisors.com/mailman/listinfo/accessd>,<mailto:accessd-request at databaseadvisors.com?subject=unsubscribe>
>List-Archive: <http://databaseadvisors.com/pipermail/accessd>
>List-Post: <mailto:accessd at databaseadvisors.com>
>List-Help: <mailto:accessd-request at databaseadvisors.com?subject=help>
>List-Subscribe: 
><http://databaseadvisors.com/mailman/listinfo/accessd>,<mailto:accessd-request at databaseadvisors.com?subject=subscribe>
>Errors-To: accessd-bounces at databaseadvisors.com
>Return-Path: accessd-bounces at databaseadvisors.com
>
>This question is akin to the Library Database structure poser a couple days 
>ago.
>
>Checkboxes against roles work, but your giving up some normalization there. 
>  A junction table between the Entity and the Role is a more normalized 
>approach.  You'll give up a bit of speed as the number of records involved 
>in a query and its index goes up to the number of entities times the 
>average number of roles so the size of the data to be joined goes up in 
>proportion to the additional number of records and of course, the 
>processing of the join involves more processor cycles so the normalization 
>may bite a bit.  For better speed you can go with the flatter checkbox 
>approach, and for faster yet, that whole query by join on a bit will get 
>you 8 categories in a single byte field.  But I digress...
>
>For a law office database with similar considerations, I used a parent form 
>with a lookup combo and some search and navigation buttons that covered all 
>categories.  This parent form contained the basic universal information 
>about the person/corporate body.  When the user selected a person or 
>corporate body, various tabs became visible, each containing a subform that 
>had records pertaining to that category.  Generally, records within a 
>subform category were added from the subform and if no records existed, the 
>subform was simply not visible.  The user could pick a type of record from 
>the parent that would force the addition and display of an appropriate 
>subform.  For example, if a name happened to be that of a person on whose 
>behalf we had acted, a subform would open displaying the file numbers and 
>the capacity in which the person was related to the file.  A subform with 
>related parties showed the corporate bodies to which he was related as well 
>as the capacity in which he is related.  If the person was also a client on 
>a real estate transaction and his spouse was on the title, that name showed 
>as spouse.  There is another subform that contains Addresses and a further 
>one with Phone contact information.  In such a case, the person could be 
>related as a client.  If that person was also a lawyer, the related files 
>subform shows file numbers and capacity (opposing counsel, other lawyer on 
>a real estate transaction) and the related parties subform shows his legal 
>firm, assistant, reception...  If you happened to have spouse, child or 
>other affiliation, one simply needs to add that person and select a 
>capacity.
>
>I did the same thing with addresses and phone numbers.  An address could be 
>information about a property being bought or sold, but it is likely also a 
>past or present address of a client effective as at a certain date.  The 
>address of a corporation connected as a location address (as opposed to 
>mailing address) would also be the business address of a person associated 
>to the business as an employee or a lawyer.  The master address form has 
>subforms showing related parties, the capacity of the relation (home, 
>office..), related files where the property is related to a file (sale, 
>lien, tax appeal) and related phone numbers (If a law firm has the address, 
>a switchboard number is also a number for the lawyers and assistants and 
>individuals can have direct lines as well).
>
>The master phone number form has subforms that display addresses (if they 
>exist.  For a cell, the address subform would not be visible), parties that 
>may be reached by the number and their association to that number.
>
>Using JIT subforms where you set the recordsource on the fly to an 
>appropriately parameterized query makes this real fast.
>
>It is easy to control phone number formatting and I allow users to enter 
>phone numbers directly in a subform.  Before adding, the system looks up 
>the number and if it exists, displays related parties and the relationship 
>in a pop up.  This is useful in determining relationships between parties.  
>Addresses are more difficult in that there are many variations in 
>abbreviations and format.  I just have users follow Canada Post guidelines 
>and provide a merge feature to combine related addresses to keep down 
>duplications.Ciao
>Jürgen Welz
>Edmonton, Alberta
>jwelz at hotmail.com
>
>
>
> > Date: Thu, 26 Jan 2006 15:23:58 -0500> From: 
>John.Clark at niagaracounty.com> > First, I've started two requests for help 
>over the past couple of days,> only to discover the problem, while actually 
>typing the Emails...see,> y'all have learned me some things, since I've 
>been hanging out here.> > Well, it appears my luck may have run out. 
>Actually, I can think of a> couple different ways to do what I am now 
>trying to do, but I want to do> it correctly...something else I've learned 
>here...so I want to run it by> the list members.> > First I'll give you a 
>little background on the program, which is being> written in A2K. It is a 
>case tracking program for our DA's office, and I> have chosen to lump all 
>names together (i.e. lawyers, defendants,> victims, judges, etc.) in a 
>single table and, using checkboxes,> designate what role(s) they fulfill. 
>The purpose of doing this was to> avoid missing people already in the 
>system, in another designation than> they are currently being entered as. 
>It is usefull for them to know if a> defendant has been a victim, or visa 
>versa, and theoratically, a name> can be in the system as all of these 
>designations. I used the scenario> of an ADA, who becomes a defense 
>attorney, then become a judge, then> they are mugged, thus becoming a 
>victim, which makes them lose it and> take revenge on their attacker, which 
>makes them a defendant...they> would then be in all categories...unlikely 
>but possible.> > So, I've got a form called frm_Subjects, which allows 
>entry of names> and their "designations." The main form of the program is 
>the form,> "frmIndictments" and on this form, which basically a case by 
>case entry,> there is a drop down box to choose a defendant, from a list of 
>names.> Using a union query, I have set the top option to be, "".> When 
>they choose this option, I want to take them to the "frm_Subjects"> form. 
>OK, I'm good up to this point.> > The problem is however, can I use this 
>same form, yet have it react> differently? For instance, I've already got 
>it opening up as an "entry> form" with the way I am calling it from the 
>parent form (i.e.> "DoCmd.OpenForm "frm_Subjects", acNormal, , , 
>acFormAdd,> acWindowNormal"). But, when I exit that form it returns to the 
>menu, as> I've told it to do, and as I normally would want it to do. But, 
>when it> is accessed via the other form, I want it to return to that form, 
>and> place the chosen name into the combo box, which is bound to the 
>table.> > The possibilites I've thought of so far are:> > 1) set up a 
>parameter in the On Open event of that form...I don't even> know if this is 
>possible, now that I'm thinking about it...and check for> this when I have 
>it do things. Maybe it defaults to a "0" and works the> way it is now 
>working, but if called from the other form, it gets a "1"> and does things 
>slightly different.> > or 2) Cut my losses and just make a copy of the form 
>and have this copy> do the different actions, and call this one from the 
>other form. I'm> guessing this will be the answer.> > Thank you!> > John W 
>Clark
>_________________________________________________________________
>Express yourself instantly with MSN Messenger! Download today it's FREE!
>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>--
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com





More information about the AccessD mailing list