Hi Michael,
Try putting an @Override flag on the line before this method. If you
really aren't overriding it, this will cause the method to throw a
compiler error.
If it doesn't complain, it means that the code calling this method is
calling the _Invoice version of the method directly
I had a similar problem with Oracle a while ago. Queries run from the
command line or a SQL editor took far less time than ones generated by
EOF. In the end, it turned out that the problem was related to using
parameter passing (since EOF always parameterized the queries... it
was really
On Sep 17, 2008, at 06:18, David Avendasora wrote:
If it doesn't complain, it means that the code calling this method
is calling the _Invoice version of the method directly somehow.
I believe it is possible to do this using reflection. It however
should not be happening, unless you are
FrontBase doesn't do that. At least not in the versions I used.
cug
On 17.09.08 07:42, Ken Anderson [EMAIL PROTECTED] wrote:
I had a similar problem with Oracle a while ago. Queries run from the
command line or a SQL editor took far less time than ones generated by
EOF. In the end, it
On Sep 17, 2008, at 9:56 AM, Florijan Stamenkovic wrote:
When you created the instance you are now trying to update, did you
insert it into an editing context?
What's your point Dave? I don't see how this would influence the
runtime binding of methods.
I've seen weird things happen if
It sounds like your inheritance tree is not what it should be
(Invoice does not subclass _Invoice).
I'm 100% with Florijan here. You're confusing your classes somehow
and putting that method in the wrong place. You couldn't end up with
an actual _Invoice because those _Classes (at least in
The object is in the EC.
I've tried changing Invoice method from
setInvoiceStatusRelationship(InvoiceStatus value) to
setInvoiceStatus(InvoiceStatus value)
Now setInvoiceStatus in Invoice does get exceuted, however I am not
able to call super.setInvoiceStatusRelationship(value) because
Joshua, some DB's like results are the same as their case
insensitive variety. I'm not sure about FrontBase, but it may be worth
a try.
-G
On Sep 17, 2008, at 6:42 AM, Ken Anderson wrote:
I had a similar problem with Oracle a while ago. Queries run from
the command line or a SQL editor
Hmmm... Well this is my _Invoice class:
// $LastChangedRevision: 5074 $ DO NOT EDIT. Make changes to
Invoice.java instead.
package auction;
import com.webobjects.eoaccess.*;
import com.webobjects.eocontrol.*;
import com.webobjects.foundation.*;
import java.math.*;
import java.util.*;
import
I've tried changing Invoice method from
setInvoiceStatusRelationship(InvoiceStatus value) to
setInvoiceStatus(InvoiceStatus value)
Now setInvoiceStatus in Invoice does get exceuted, however I am not
able to call super.setInvoiceStatusRelationship(value) because they
start calling each
this is what I've tried:
public void setInvoiceStatus(InvoiceStatus value) {
System.out.println(updating invoice status);
if(value != invoiceStatus()) {
System.out.println(updating invoice status date);
Wonder's automatic inverse relationship stuff
What's that? Mind explaining briefly, or pointing out where it is in
wonder?
call super.setXxx
As far as I can see your _Entity (http://webobjects.mdimension.com/
wolips/EOGenerator/Velocity%20EOGenerator%20Templates/_Entity.java)
does
takeStoredValueForKey(value, INVOICE_STATUS_KEY);
or super.setInvoiceStatus(...) (NOT the relationship one) which does
pretty much this
ms ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev
I've added takeStoredValueForKey(value, INVOICE_STATUS_KEY); and now
it works! Thank you so much. I was totally confused.
Michael
Aspire Auctions
216-231-5515
www.aspireauctions.com
On Sep 17, 2008, at 11:26 AM, Florijan Stamenkovic wrote:
On Sep 17, 2008, at 10:56, Michael Kondratov
Wonder's automatic inverse relationship stuff
What's that? Mind explaining briefly, or pointing out where it is in
wonder?
On ERXGenericRecord:
* Also, this class supports auto-updating of inverse relationships.
You can
* simply call codeeo.setFoo(other), eo.takeValueForKey(other),
*
There is no setInvoiceStatus in _Invoice. Only
setInvoiceStatusRelationship.
Now, I assume that _Invoice.setInvoiceStatusRelationship gets called
first and in turn calls Invoice.setInvoiceStatus .
Is that correct?
On Sep 17, 2008, at 11:35 AM, Mike Schrag wrote:
On Sep 17, 2008, at 12:02, Michael Kondratov wrote:
There is no setInvoiceStatus in _Invoice. Only
setInvoiceStatusRelationship.
See what Mike was just saying...
Now, I assume that _Invoice.setInvoiceStatusRelationship gets
called first and in turn calls Invoice.setInvoiceStatus .
Is
Hi all,
If you check out the docs for EOCustomObject's takeValueForKey and
takeStoredValueForKey you will see that there is talk of storing the
value in instance variables (_key or key), but there is not talk
about storing values in a value dict, which is what most likely
happens in the
This is probably a relic of legacy documentation. Long, long ago in
a language far, far away from Java, EOCustomObject kept the values in
instance variables and EOGenericRecord kept them in a dictionary. I
don't know if anyone even uses EOCustomObject these days nor what it
does now.
On 17.09.08 10:02, Michael Kondratov [EMAIL PROTECTED] wrote:
There is no setInvoiceStatus in _Invoice. Only
setInvoiceStatusRelationship.
Then you are using either a very old WOLips or some old templates.
cug
___
Do not post admin requests to
Actually, I am running on Oracle. Not sure where this Frontbase
notion started. :-)
I will look into Ken's suggestion below, that might do the trick.
-Josh
On Sep 17, 2008, at 8:00 AM, George Domurot wrote:
Joshua, some DB's like results are the same as their case
insensitive variety.
Joshua,
I will bet you plenty of money that it will!
Ken
On Sep 17, 2008, at 2:58 PM, Joshua Dubey wrote:
Actually, I am running on Oracle. Not sure where this Frontbase
notion started. :-)
I will look into Ken's suggestion below, that might do the trick.
-Josh
On Sep 17, 2008, at
Hi guys,
@Chuck: Thank you for your quick response and sorry for the direct
reply.
It is now working with ERXApplication, ERXSession, ERXDirectAction and
ERXComponent, have not used ERXGenericRecord so far, because I do not
know which template I have to use for the EOGenerator. Actually
On 17.09.08 12:58, Joshua Dubey [EMAIL PROTECTED] wrote:
Actually, I am running on Oracle. Not sure where this Frontbase
notion started. :-)
You never denied I think. But we should have guessed Oracle from the missing
indexes and slow responses ... ;-) *bash bash*
Yeah, disabling prepared
On Sep 16, 2008, at 7:35 PM, Joshua Dubey wrote:
SELECT bunch of attributes, from ORDERS T0 WHERE
UPPER(T0.EMAIL_ADDRESS) LIKE UPPER('[EMAIL PROTECTED]') ESCAPE '\;
In general... 'like' predicates are tricky to optimize from a SQL
engine point of view...
In Oracle... for simple case
On Sep 17, 2008, at 8:58 PM, Joshua Dubey wrote:
I will look into Ken's suggestion below, that might do the trick.
From a database perspective... not using bind variables is, hmmm,
suicidal.
Just my 2¢.
Cheers,
--
PA.
http://alt.textdrive.com/nanoki/
Begin forwarded message:
From: Daniel Beatty [EMAIL PROTECTED]
Date: September 17, 2008 5:56:24 PM CDT
To: David Avendasora [EMAIL PROTECTED]
Cc: Daniel Beatty [EMAIL PROTECTED]
Subject: Re: Cappuccino
Greetings David,
A really odd twist to your suggestion would be a some kind
complement
27 matches
Mail list logo
