On Mar 13, 2010, at 6:00 PM, FMPRO-L automatic digest system wrote: > There are 4 messages totalling 175 lines in this issue. > > Topics of the day: > > 1. Related record creation (3) > 2. Choosing a printer ... permanently > > ---------------------------------------------------------------------- > > Date: Fri, 12 Mar 2010 17:42:58 -0600 > From: Steve Abrahamson <[log in to unmask]> > Subject: Re: Related record creation > > Barrie, > > What field are you typing into in the portal? Thanks Steve I'm typing into a text field. In this case the portal to the related table contains only a text field, two date fields, and a check box that are visible. The 'person' ID number, current record flag (yes/no) and the concatenation of the two (the match field) are hidden beneath the four entry fields. > > > Steve Abrahamson > Ascending Technologies > FileMaker Certified Developer > http://www.asctech.com > [log in to unmask] > > > On Mar 12, 2010, at 4:19 PM, Barrie Phillips wrote: > >> I'm working with a database with 11 tables, in FMP Advanced 9.5 on >> a = > Mac. >> =20 >> The main 'People' table contains the names and ID numbers (and >> other = > information) of all the individuals in the database. Because it is = > important that I keep track of any edits to any of the records, > edits = > are done non-desctructively. I do this by considering each original = > record (or the last edited version) to be 'current', and since I = > generally only want to display 'current' records the match field > between = > all the tables is the concatenation of the ID number and the > 'current' = > indicator (yes/no). During the edit process the original record is = > duplicated but the 'current' flag is set to 'No', and the edit is > made = > to the new record. >> =20 >> The individuals are added to a 'People' table at which time the ID = > number (this is a 'person' ID number and not a serial record ID > number) = > is assigned consecutively and the record is set as current. All the = > remaining tables are presented in portals on six tabbed cards, > several = > of which contain their own nested sub-cards. The cards are set to > show = > data from the 'People' table, while the portals show data from the = > related tables. The match fields for both the 'Individual' field and > the = > related field are on the card (with data from the 'Individuals' > table) = > and in the related portal. >> =20 >> My problem is that despite the fact that the relationships are set >> up = > to allow record creation in the related table from the 'People' > table I = > cannot do so by simply placing the cursor in a field in the portal > and = > typing. I get a message telling me that the field is not modifiable. > I = > can make it work by including a scripted button on the portal row to = > create a new record in the related table, and everything works fine. = > However, I shouldn't have to explicitly script record creation and I = > cannot figure out what I'm doing wrong. >> =20 >> I'm not certain if this is enough information, but I would >> appreciate = > any help you might be able to offer. > > ------------------------------ > > Date: Sat, 13 Mar 2010 01:08:16 -0500 > From: Bruce Herbach <[log in to unmask]> > Subject: Re: Related record creation > > Hi Barrie, > > A couple of quick things to check. First make sure the field you > click > into is a text or number field and not a calculation. Next make sure > the field is set up so that it can be entered in Browse mode. Either > one of these things could produce a message similar to what you are > getting. > > I hope this helps > Bruce Herbach Thanks Bruce Check and Check. It is a text field and can be entered in browse mode. > > Barrie Phillips wrote: >> I'm working with a database with 11 tables, in FMP Advanced 9.5 on >> a Mac. >> >> The main 'People' table contains the names and ID numbers (and other >> information) of all the individuals in the database. Because it is >> important that I keep track of any edits to any of the records, edits >> are done non-desctructively. I do this by considering each original >> record (or the last edited version) to be 'current', and since I >> generally only want to display 'current' records the match field >> between all the tables is the concatenation of the ID number and the >> 'current' indicator (yes/no). During the edit process the original >> record is duplicated but the 'current' flag is set to 'No', and the >> edit is made to the new record. >> >> The individuals are added to a 'People' table at which time the ID >> number (this is a 'person' ID number and not a serial record ID >> number) is assigned consecutively and the record is set as current. >> All the remaining tables are presented in portals on six tabbed >> cards, >> several of which contain their own nested sub-cards. The cards are >> set >> to show data from the 'People' table, while the portals show data >> from >> the related tables. The match fields for both the 'Individual' field >> and the related field are on the card (with data from the >> 'Individuals' table) and in the related portal. >> >> My problem is that despite the fact that the relationships are set up >> to allow record creation in the related table from the 'People' table >> I cannot do so by simply placing the cursor in a field in the portal >> and typing. I get a message telling me that the field is not >> modifiable. I can make it work by including a scripted button on the >> portal row to create a new record in the related table, and >> everything >> works fine. However, I shouldn't have to explicitly script record >> creation and I cannot figure out what I'm doing wrong. >> >> I'm not certain if this is enough information, but I would appreciate >> any help you might be able to offer. >> > > ------------------------------ > > Date: Sat, 13 Mar 2010 00:14:44 -0600 > From: John French <[log in to unmask]> > Subject: Re: Choosing a printer ... permanently > >>> ... when I opened the recovered file, lo and behold, the problem >>> appeared to have been cured! I changed the printer from Printer B >>> to Printer A, and upon closing and reopening the database, Printer >>> A was still the default. Also, selecting a different record and >>> layout was preserved across a close and reopen. >>> >>> I can't explain exactly what may have been wrong with the >>> unrepaired database; but, for now at least, I think I'm good to go. >>> Thanks to all who offered ideas and advice; and the kewpie doll >>> goes to Tim Mansour, who raised the possibility of file corruption. >> >> There was likely nothing wrong with the database. If you go back to >> the Recover dialog and specify the "Advanced" options you'll see that >> one of the options is to "Delete cached settings." If you had >> selected >> only this option you likely would have seen the same thing. >> >> Look at your Recover Log. It will tell you if the recover process >> changed anything or not. > > Fortunately, I left the problematic file around as back-up until I > became confident in the recovered file. Copying the original version > and performing a limited recovery on it, per the above suggestion, > shows that the analysis and suggested correction is spot on! Had I > been smarter or the option for deleting the cached settings not been > hidden, I could have cured my problem much more definitively, for the > benefit of those watching over my shoulder during this thread. > > I guess since I'd already awarded a kewpie doll to the person whose > indirect analysis led to my indirect "solution", I should award two > kewpie dolls to Cornelius Walker for his completely correct analysis > and solution. Thanks, Corn; care to conjecture as to how the Printer > B setting came to be cached in the first place? That's about the only > puzzle still left standing. > > ------------------------------ > > Date: Sat, 13 Mar 2010 18:05:58 +1100 > From: Tim Mansour <[log in to unmask]> > Subject: Re: Related record creation > > Can you tell us what the exact relationship is between the parent > record and the related record? (ie, which fields are included in the > relationship on each side) Thanks Tim, The match field is a calculation, the concatenation of the 'person' ID number and the current record indicator (yes/no). When the related record is created manually using a scripted button the subject number is entered, the current indicator is set to 'yes' automatically and the match field is populated by calculation. I realize that this may be the source of the problem, but I can't find a way around it. > > -- > Tim Mansour <[log in to unmask]> > Neologica Print & Promotions ABN 63 904 335 408 > PO Box K1163 : Haymarket NSW 1240 > Mobile 0405 500 846 : Melbourne in-dial 03 9012 7441 > > ------------------------------ > > End of FMPRO-L Digest - 12 Mar 2010 to 13 Mar 2010 (#2010-42) > *************************************************************