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,