So kinda still at square one -- don't know how (or if) FM will handle
changing the field in the middle of generating xrefs and how to do this
(whether to call FM to set the field value to empty or to use @ to delete
the field while inside the xref fire). Guess I'll have to do some
I will have to look. Isn't there a file DDnode that will run a routine in the pre-edit stage prior to actually doing the edit. I also vaguely remember that there was a way to get FM to quit the edit session at that point. This is all from memory.
On 3/8/06, Dan [EMAIL PROTECTED] wrote:
So kinda
@lists.sourceforge.net
Subject: RE: [Hardhats-members] field uniqueness (key index but null
allowed)
For each record the field could either have a value or could be empty --
more than one record could have the field empty. If the field has a value
the value has to be unique within the other records that have
Aren't Input Transforms only executed when passing external values via
FileMan DB calls?
At 01:41 PM 3/7/2006, Cameron wrote:
A simple regular cross-reference on the field could keep track of all values
used in that field. Put your logic in the Input Transform. Note that the
SSN field in
07, 2006 12:43 PM
Subject: RE: [Hardhats-members] field uniqueness (key index but null
allowed)
Aren't Input Transforms only executed when passing external values via
FileMan DB calls?
At 01:41 PM 3/7/2006, Cameron wrote:
A simple regular cross-reference on the field could keep track of all
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James
Gray
Sent: Tuesday, March 07, 2006 1:51 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] field uniqueness (key index but null
allowed)
You aren't planning to put data into this field any other way than through
PROTECTED]
To: hardhats-members@lists.sourceforge.netSent: Tuesday, March 07, 2006 12:43 PMSubject: RE: [Hardhats-members] field uniqueness (key index but null
allowed) Aren't Input Transforms only executed when passing external values via FileMan DB calls? At 01:41 PM 3/7/2006, Cameron wrote:A
Three ways!
Thanks, Steve!
Cameron
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven McPhelan
Sent: Tuesday, March
07, 2006 4:18 PM
To:
hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members]
field uniqueness (key
That's the whole problem -- if another programmer uses a db call with
internal values then the Input Transform rules would be bypassed, leading
to the possibility of duplicate entries.
One could provide a special API for handling that field but once again if
somebody doesn't use that API
@lists.sourceforge.net
Subject: RE: [Hardhats-members] field uniqueness (key index but null
allowed)
That's the whole problem -- if another programmer uses a db call with
internal values then the Input Transform rules would be bypassed, leading
to the possibility of duplicate entries.
One could provide a special
Do you mean that only one record would have null in the given field? That
is, null would be in the set of permitted values in the field and that no
value (including the null value) would be repeated in any record?
You would have to insure uniqueness -before- allowing the record to persist,
so it
For each record the field could either have a value or could be empty --
more than one record could have the field empty. If the field has a value
the value has to be unique within the other records that have a non-empty
value for the field.
At 10:28 PM 3/5/2006, Cameron wrote:
Do you mean
12 matches
Mail list logo
