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
Hi David,It's a wonder application.Not a D2W.
Saludos,
Oscar.
CC: webobjects-dev@lists.apple.com
From: programming...@mac.com
Subject: Re: Localizable.strings
Date: Tue, 2 Oct 2012 16:45:06 -0700
To: racso...@hotmail.com
D2W? If so what are your rules?
Sent from my iPad
On 2012-10-02, at
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
Thanks David for your help,
The way it works.MgeProductor.MgeProductor = Productor;
If you want to localize an entity nameyourEntityName.yourEntityname =
something;
Thanks,
Oscar.
From: racso...@hotmail.com
To: programming...@mac.com
Subject: RE: Localizable.strings
Date: Wed, 3 Oct 2012
Le 2012-10-02 à 18:02, Roger Perryman ro...@xeotech.com a écrit :
The following is just an update in case anyone stumbles upon this same
problem. Not really a full solution but perhaps useful none the less.
I was not able to get SVN+SSH in Jenkins to work on an OSX 10.6.7 system that
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.
13 matches
Mail list logo
