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)
> *************************************************************