Hi Paul,
derived attributes are computed by the database and thus those values are
only updated when an eo is fetched into memory. In your case you are creating a
new eo that has NULL for these attributes and as long as WO uses that eo or its
snapshot cache those values will be still NULL. You
Hi Johann,
On 03/10/2012, at 5:26 PM, Johann Werner wrote:
derived attributes are computed by the database and thus those values are
only updated when an eo is fetched into memory. In your case you are creating
a new eo that has NULL for these attributes and as long as WO uses that eo or
Hi Paul,
FWIW, I made a small change to ERXGenericRecord (integration branch) recently
that allows valueForKey( primaryKeyAttributeName ) to read the PK value
using id or whatever you use for PK field names to be used. This was to allow
a fetch qualifier qualified on the primary key
Or just make it a class property. Some people find that offensive, but it
won't cause problems for EOF. Exposed FK does cause problems.
Chuck
On 2012-10-03, at 1:34 AM, Paul Hoadley wrote:
Hi Johann,
On 03/10/2012, at 5:26 PM, Johann Werner wrote:
derived attributes are computed by
On 03/10/2012, at 10:10 PM, Kieran Kelleher wrote:
FWIW, I made a small change to ERXGenericRecord (integration branch) recently
that allows valueForKey( primaryKeyAttributeName ) to read the PK value
using id or whatever you use for PK field names to be used. This was to
allow a
Hi Chuck,
On 04/10/2012, at 1:53 AM, Chuck Hill wrote:
Or just make it a class property. Some people find that offensive, but it
won't cause problems for EOF. Exposed FK does cause problems.
I'm not one of those people, and I did consider that. What I've done instead
is used the
On 2012-10-03, at 2:09 PM, Paul Hoadley wrote:
Hi Chuck,
On 04/10/2012, at 1:53 AM, Chuck Hill wrote:
Or just make it a class property. Some people find that offensive, but it
won't cause problems for EOF. Exposed FK does cause problems.
I'm not one of those people, and I did
On 04/10/2012, at 6:45 AM, Chuck Hill wrote:
I'm not one of those people, and I did consider that. What I've done
instead is used the opportunity to look at ERXSequence and
NativeDatabaseSequence in particular. This is one of those perennial
invoice number situations, where all I really
On 2012-10-03, at 3:50 PM, Paul Hoadley wrote:
On 04/10/2012, at 6:45 AM, Chuck Hill wrote:
I'm not one of those people, and I did consider that. What I've done
instead is used the opportunity to look at ERXSequence and
NativeDatabaseSequence in particular. This is one of those
On 04/10/2012, at 8:25 AM, Chuck Hill wrote:
I would NOT be in favour using the PK as in invoice number. That IS
offensive! :-P
Heh. I guess it depends on your requirements for an invoice number.
I just object to the use of the PK for a piece of data that has meaning to
the user.
10 matches
Mail list logo