AML throws Aras.Server.Core.AmbiguousCriteriaException

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?

Parents

Offline majorbyte over 7 years ago

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.

Reply

Offline majorbyte over 7 years ago

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.

Children

No Data