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