Update
Thanks for updating with more detail. Leaving the original response below for those that may need it regarding parent/child.
I've never seen the selector defined with reference to Current<> and no Current WHAT. To be honest, I'm surprised it compiled. "Where Field = Current View Field" directs the selector to limit results to only values associated to the Current value of whatever field you specified, and it is retrieved from the "ViewName.Current" record in the graph. Your where clause does not tell it what "current" to match. Since you direct the selector to Search, I suspect that this is causing the selector to be unable to find a matching record and short-circuiting the save of the result for that field.
It sounds like TASKDAC is a "master data" type record, defining all possible tasks to be performed. Therefore, TaskID is not a key field in STEPDAC but rather a key field in TASKDAC. If you want to select "any" task, you don't need the where clause at all.
[PXSelector(
typeof(TASKDAC.TaskID),
typeof(TASKDAC.taskCD),
SubstituteKey = typeof(TASKDAC.taskCD)
)]
Let's assume for a moment that you designate a WORKITEMDAC.WorkOrderType that is used to filter acceptable tasks by the same field. (Only repair tasks can be assigned to a repair WorkOrderType, assembly to an assembly WorkOrderType, etc.) In this case, you would use the syntax you stated, but you would designate Where<TASKDAC.WorkOrderType, Equal<Current<WORKITEMDAC.WorkOrderType>>. If the task is limited to something in the STEPDAC instead, just swap out WORKITEMDAC with the STEPDAC field in the example below.
[PXSelector(
typeof(Search<TASKDAC.TaskID,
Where<TASKDAC.WorkOrderType, Equal<Current<WORKITEMDAC.WorkOrderType>>>>),
typeof(TASKDAC.taskCD),
SubstituteKey = typeof(TASKDAC.taskCD)
)]
Please update your PXSelector and advise if that fixes the issue or what error you get next.
Original Response
With so little to your question, the nature of your question is very unclear. It sounds like you are attempting to do something that should perhaps take a different approach. The definition of a selector should not impact the saving of a field, but the structure of a parent child relationship is critical to define properly. As such, it seems very odd that you would have a Child ID that differs from the parent and that it would be used in a selector.
Typically, the child DAC shares an ID with the parent DAC. We often define a LineNbr field in the child which is given a value by PXLineNbrAttribute, and the Key fields would be ID + LineNbr to identify a specific child record. We also set SyncPosition = true in the ASPX document on the grid so that the user interface stays completely sync'd with whichever record the user has selected in the grid. Parent Child relationships can be daisy chained, such as with SOOrder -> SOLine -> SOLineSplit, but ultimately, the ID field of a child is not a selector... the ID of the parent is.
Think of a selector as a means of looking up master data. Master data may be related to other data, but it would not have a parent in most cases. There are exceptions, but let's keep it simple. A purchase order, for instance, would not have parent, and the key field would be a common selector field. However, since a child must always relate to its parent and cannot change its parent, the ID of the child field would not be a selector. Other tables in Acumatica would refer back to some field or combination of fields to relate to the data of a child DAC.
From the T210 training guides, I stripped away a lot to show just this point.
RSSVRepairPrice - Parent
using System;
using PX.Data;
namespace PhoneRepairShop
{
[PXCacheName("Repair Price")]
public class RSSVRepairPrice : IBqlTable
{
#region PriceID
[PXDBIdentity]
public virtual int? PriceID { get; set; }
public abstract class priceID : PX.Data.BQL.BqlInt.Field<priceID> { }
#endregion
#region ServiceID
[PXDBInt(IsKey = true)]
[PXDefault]
[PXUIField(DisplayName = "Service", Required = true)]
[PXSelector(
typeof(Search<RSSVRepairService.serviceID>),
typeof(RSSVRepairService.serviceCD),
typeof(RSSVRepairService.description),
DescriptionField = typeof(RSSVRepairService.description),
SelectorMode = PXSelectorMode.DisplayModeText)]
public virtual int? ServiceID { get; set; }
public abstract class serviceID : PX.Data.BQL.BqlInt.Field<serviceID> { }
#endregion
#region RepairItemLineCntr
[PXDBInt()]
[PXDefault(0)]
public virtual Int32? RepairItemLineCntr { get; set; }
public abstract class repairItemLineCntr : PX.Data.BQL.BqlInt.Field<repairItemLineCntr> { }
#endregion
}
}
RSSVRepairItem - Child
using System;
using PX.Data;
using PX.Objects.IN;
using PX.Data.BQL.Fluent;
namespace PhoneRepairShop
{
[PXCacheName("Repair Item")]
public class RSSVRepairItem : IBqlTable
{
#region ServiceID
[PXDBInt(IsKey = true)]
[PXDBDefault(typeof(RSSVRepairPrice.serviceID))]
[PXParent(
typeof(SelectFrom<RSSVRepairPrice>.
Where<RSSVRepairPrice.serviceID.IsEqual<
RSSVRepairItem.serviceID.FromCurrent>>
))]
public virtual int? ServiceID { get; set; }
public abstract class serviceID : PX.Data.BQL.BqlInt.Field<serviceID> { }
#endregion
#region LineNbr
[PXDBInt(IsKey = true)]
[PXLineNbr(typeof(RSSVRepairPrice.repairItemLineCntr))]
[PXUIField(DisplayName = "Line Nbr.", Visible = false)]
public virtual int? LineNbr { get; set; }
public abstract class lineNbr : PX.Data.BQL.BqlInt.Field<lineNbr> { }
#endregion
}
}
In the parent, notice the use of PXDBIdentityAttribute which specifies that the record identity is set by the database in PriceID. The "ID" field used by the child is taken from the ServiceID field which is defined as a selector for another master table. The use of IsKey = true on PXDBIntAttribute tells Acumatica that it can find the unique record by the combination of all the fields marked IsKey = true. (Note that the actual training guide includes another field as part of the key, but I simplified the example here.) Also notice the use of a PDXBInt field that has a default of 0 to be used as a Line Counter. (RepairItemLineCtr)
Now, in the child, notice that the key field of the parent is defined again in the DAC, but without the selector. The PXParentAttribute defines the relationship back to the parent DAC, and the field value is defaulted in from that parent. This is what causes the value to be saved in the record automatically. It also associates the relationship so that deleting the parent will delete the child as well. Notice the use of PXLineNbrAttribute to autoincrement the field of the parent DAC and set the value in the LineNbr field. It is the combination of these 2 fields that points you to the exact record.
There are cases where Acumatica uses the NoteID field (a unique GUID value) to identify a record of a child DAC, but this is a bit more complex. You can see it in the relationship of INItemPlan (Demand) to Purchase Orders.
If you are having trouble with Parent-Child (Master-Detail) relationships, I'd highly recommend reviewing the T210 training course.
