• Replies 5 replies
  • Subscribers 10 subscribers
  • Views 6183 views
  • Users 0 members are here
Options
Related

AML throws Aras.Server.Core.AmbiguousCriteriaException

majorbyte
Offline
I'm trying to update the datasource of a property to the correct datasource in our test and production environments, but without the use of ID's because that's what caused the problem I'm trying to correct in the first place, the id's for (for instance) properties in test and production don't always match the id's in our development environment. So, I wrote this AML: 
<Item action="edit" type="Property" where="[Property].keyed_name = 'era_locked_by'">
  <data_source keyed_name="locked_by_id">
    <Item type="Property" action="get" select="id" where="[property].keyed_name = 'locked_by_id' and [property].source_id in (select it.ID from innovator.ITEMTYPE it where it.name = 'DOCUMENT')" />
  </data_source>
</Item>
but when I run in Innovator Admin for instance, it returns <af:exception message="Aras.Server.Core.AmbiguousCriteriaException" type="Aras.Server.Core.AmbiguousCriteriaException" /> This is probably because of the nested Properties where statement, but is there any to make this work, without using actual id's?
  • Offline
    Your first where="[Property].keyed_name = 'era_locked_by'" is too "general" There can be more than one property with the name "era_locked_by". Try to add and [Property].source_id = (select id from [ItemType] where name ='{YOUR_ITEM_TYPE_NAME}') In your second where try to keep names of ItemType as it in Aras: where="[Property].keyed_name = 'locked_by_id' and [Property].source_id in (select it.ID from innovator.ITEMTYPE it where it.name = 'Document')"
  • Offline
    Thanks for your response, Zahar. Our SQL instance is case-insensitive, so the second where works as it should, if I run the <item> inside the datasource on its own, it returns: 
    <Result>
      <Item type="Property" typeId="26D7CD4E033242148E2724D3D054B4D3" id="07912B9CE3374ABFAACF1B19B3F6F718">
        <id keyed_name="locked_by_id" type="Property">07912B9CE3374ABFAACF1B19B3F6F718</id>
      </Item>
    </Result>
    I'm aware as well about the first where, but currently we only have one property with that name. I'm trying to achieve: 
    UPDATE innovator.[PROPERTY]
SET DATA_SOURCE = (
	SELECT [PROPERTY].id id
	FROM innovator.[PROPERTY]
	WHERE keyed_name = 'locked_by_id' AND [Property].source_id in (select IT.ID from innovator.ITEMTYPE IT where IT.name = 'Document') )
WHERE [Property].keyed_name = 'era_locked_by'
    But I get the feeling that AML can't cope with nested where statements. I'm missing something but I can't put my finger on it.
  • Offline
    I managed to get it working by rewriting the inner where statement to a nested <Item action=get> 
    <Item action="edit" type="Property" where="[Property].keyed_name = 'era_locked_by' and [Property].source_id = (select id from [ItemType] where name ='Document')">
    <data_source keyed_name="locked_by_id">
      <Item type="Property" action="get" select="id">
        <keyed_name>locked_by_id</keyed_name>
        <source_id>
          <Item type='ItemType' action='get'>
            <name>Document</name>
          </Item>
        </source_id>
      </Item>
    </data_source>
  </Item>
    So my initial feeling was (probably?) right, that AML can't copy really well with nested where-statements.
  • Offline
    majorbyte, Good catch. Actually now I remember that I had this question to Aras support some time ago and they told me, not to use where condition for setting properties. So you right. One comment about "case sensitivity", you right it will work, but for my opinion it good idea to keep your code as cleaner and close to original names of ItemTypes as possible. It will be easier for you or other developer to read this code and understand what you wanted to do.
  • Offline
    So, to answer my own question, because I ran into this issue again (and yeah I forgot this). It works fine for properties on itemtypes that have actual relations in the database, i.e. source_id on a item_type that has a relation to another table. Data_source on the other hand, does not have a relation to other tables, because data_source can be of type List as well, therefor a SQL WHERE statement wouldn't work that well on the data_source column/property