|Cannot find object feature using ETL even though the object feature already exists [message #635073]
||Mon, 25 October 2010 11:06
| James Sharp
Registered: September 2010
I am occasionally getting an odd error message when running ETL:
Property 'name' not found in object Parameter [name=v_reset]
From the looks of the error message, the object Parameter has the name attribute specified? How can this therefore be an error?
The line that creates this error message is:
hStatement.assignsValueTo := csp!TypeItem.select
(item|vAssignment.assignValueTo.usesElement.name.isSubstring Of( "nv_" + item.name)).first();
At first I thought this may be because the rules had fired in the wrong order, but as I have now specificed my rules as @lazy and call then in an order that ensures that the Parameter object will be created before this line fires I am slightly confused why I am getting this error message.
And as I said it's appearance is sporadic and from what I can tell, completely random.
Any ideas on resolving this would be great.
|Re: Cannot find object feature using ETL even though the object feature already exists [message #635557 is a reply to message #635553]
||Wed, 27 October 2010 06:46
| Dimitrios Kolovos
Registered: July 2009
Which version of Epsilon are you using? I've noticed that in the
CaseCheckForNestedAssignment operation the parameter is named "case",
which has been a reserved word since support for switch/case was added
to Epsilon - which happened a while ago. With the latest interim version
of Epsilon I don't observe any non-determinism (the error comes from the
same line every time). Could you please update to the latest interim
version of Epsilon and give it another go? If you still can't pin this
down please let me know and I'll have a closer look at your code...
Dimitris Kolovos wrote:
> Hi James,
> I don't think I've ever encountered something similar. I'll have a look
> and let you know. Historically, the most notorious source of
> non-deterministic behaviour is the use of HashMaps - but I thought we'd
> eliminated them. I'll get back to you shortly.
> James Sharp wrote:
>> Hi Dimitris,
>> I have sent (sorry but it's the entire etl so far as this error does
>> not always pertain to the same rule.
>> Also it seems that the @primary rule does not always fire. I have been
>> fighting it all morning and whilst none of the ETL or the source model
>> have changed it is non deterministically firing my main rule...
>> (I have not upgraded any of my plug-ins or installed any new
>> plug-ins/features either)
>> Is this something that you have heard of before? It is driving me
>> crazy and I have no idea what is wrong with it.
>> Many Thanks,
Powered by FUDForum
. Page generated in 0.01647 seconds