This topic was covered well at this link:
Create DAC that inherits from other DAC
I am getting this error with a Report (.rpx) when attempting to visit it on the website:
GenericArguments[0], 'MyNamespace.DAC1', on 'PX.Data.PXCache`1[TNode]' violates the constraint of type 'TNode'.
Specifically, DAC1 contains only the "audit fields" such as CreatedByID, LastModifiedDateTime, etc. DAC2 inherits from DAC1 and only DAC2 implements IBqlTable. The MS SQL table maps to DAC2 only and it contains all fields combined. A ListView page works well for maintenance of table data, but
the report will not render if DAC1 fields are included in the report design.
I have tried adding [PXTable] to DAC2 but no luck. I wish to avoid redefining/overriding the audit fields of DAC1 into DAC2. Am I overlooking something? Should I abandon the use of DAC1 altogether? Thanks!
Related
Similar post to this:
Curious about properly defining the DAC.
I have a T-SQL CREATE VIEW script that I've added to the 'Database Scripts' are of the Customization project as shown. But I suspect that I haven't added the DAC properly. When I attempt to add this DAC within the context of a Generic Inquiry 'Add Related table' screen I do not get any results when searching for the name of the DAC I tried to create.
When I initially attempted to define the DAC in the 'Code' area, the system complained that the object didn't exist in the database. This makes sense as it's a SaaS instance and I've just created the T-SQL view from a local copy of the database.
So I just added the CREATE VIEW statement within the 'Database Scripts' area and published the customization successfully.(This implies to me that the object exists in the database now).
But I now believe I need to retroactively 'Generate Members from Database' in order to identify the key fields so Acumatica can see how it aligns with other DACs. Is this a correct assumption?
In the CODE area I see this (where vGFCINItemClassSeg is the name of the SQL view )
using System;
using PX.Data;
namespace vGFCINItemClassSeg
{
[Serializable]
[PXCacheName("vGFCINItemClassSeg")]
public class vGFCINItemClassSeg : IBqlTable
{
}
}
Any suggestions on how to properly provide Acumatica with what it needs to associate this to the INItemClass table in the database and make it available as a DAC?
Got this resolved.
Problem was that I had attempted to add the DAC prior to adding the Database script.
Solution: unpublish the customization package. drop the custom SQL view from the database. Start a new customization package. Add the Database Script first. THEN publish. Then after that is successful, re-open the customization project and add the DAC as a second step.
First, created a custom field in the PM.PMTask DAC called usrNumberofPanel
Second, created a custom field in the PM.PMProject DAC usrTotalPanels.
Want each of the lines from task to update the total number of panels on the project, so modified the attribute for PM.PMTask.userNumberofPanel and added a PXFormula as shown below to add the SumCalc.
[PXDBDecimal]
[PXUIField(DisplayName="Number of Panels")]
[PXFormula(null, typeof(SumCalc<PX.Objects.CT.ContractExt.usrTotalPanels>))]
Made sure the attributes for the Total Panel and set as follows to make sure no one types into the field.
[PXDBDecimal]
[PXUIField(DisplayName="Total Panels", Enabled = false)]
Any thoughts would be appreciated.
It's a known issue that SumCalc doesn't work properly across DACs that are linked with PXParent relationships.
I can only recommend to use a RowSelected or FieldSelecting graph event handlers to compute the sum instead of a solution involving DAC attributes. You can add a comment explaining the limitation of DAC attributes in the event handler if you are seeking Acumatica ISV Certification for your solution.
I have a custom table in SQL Server called AnimalBreed and maintenance page.
I wish to add User Defined Field support via the KvExt approach instead of
traditional practices involving either CSAnswers or a CacheExtension of the
DAC and underlying "Usr" fields.
Is this possible?
Can it be done for line-level (child) DACs, such as
existing INLocation and INLocationKvExt?
Thanks!
UPDATE:
It appears the feature needs at least:
ensure your table has the NoteID column as uniqueidentifier datatype and the DAC has the corresponding field: Guid? NoteID and [PXNote()] attribute.
In the ASPX, if not ListView, add the following to the PXDataSource tag:
EnableAttributes="true"
By making these changes, I can Manage User Defined Fields, choose Attributes to include, and I can store values to the KvExt table.
I am using Version = 19.205.0023
Sales Order page observation: if I add two UDFs on SO Order Entry page, one is combobox and one is checkbox, setting their values saves just fine, but then updating the combobox and save leads to loss of the checkbox (from true to false), unless you uncheck and recheck prior to the save. Is this a bug?
Maybe technically possible but definitely not recommended to use undocumented feature like KvExt.
If you need to deploy User Defined Fields on a page which already contains them. Configure them manually and then add them in a customization package in the user defined fields section for deployment as described here:
https://help-2019r2.acumatica.com/Help?ScreenId=ShowWiki&pageid=e01f29d3-b6b1-40f4-a2d1-45c9d01bdde3
Example:
I have extended INItemLotSerial table by creating a new table InfoINItemLotSerialExtNV. The Table is left joined on InventoryID & LotSerialNbr.
I am trying to use the Extended table fields in the where condition. The fields are not show up in the INItemLotSerial. Do I have to link again the table using join or Just use the InfoINItemLotSerialExtNV in where condition?
Assuming you extended INItemLotSerial DAC by declaring InfoINItemLotSerialExtNV like that:
class InfoINItemLotSerialExtNV : PXCacheExtension<INItemLotSerial>
The custom fields contained in InfoINItemLotSerialExtNV should be accessible whenever INItemLotSerial is accessible. Extension DAC fields are loaded by the framework when the base DAC is loaded.
Your query should look like:
PXSelect<INItemLotSerial, Where<InfoINItemLotSerialExtNV.customField, Equal< ... >>
In BQL expressions, you have to refer to the custom field by its BQL name in the extension class. For an example please refer to Acumatica Customization Guide. The practice shown in documentation can be applied both to the regular DAC extension and the DAC extension mapped to an extension table.
I have a form with a General Information tab. There are fields in the header and General Info tab that are bound to the same view (and thus should be a part of the same record in the Cache/Database). However, when I insert, it creates 2 records in the same table. One contains only the values for the fields in the header, the other contains only the values for the fields in the tab. I need those to be bound to the same record. What am I missing?
I got around this by declaring a second view, binding that view to the main view through the key, and assigning the tab to use the second view as its data source.
I got the idea from the EmployeeMaint BLC, where the General Info tab is distinguished from the header view using these 2 views:
public PXSelectJoin<EPEmployee, LeftJoin<GL.Branch, On<GL.Branch.bAccountID, Equal<EPEmployee.parentBAccountID>>>, Where<EPEmployee.parentBAccountID, IsNull, Or<MatchWithBranch<GL.Branch.branchID>>>> Employee;
public PXSelect<EPEmployee, Where<EPEmployee.bAccountID, Equal<Current<EPEmployee.bAccountID>>>> CurrentEmployee;
Consider that the header in the EP203000 page uses the Employee view, while the General Info tab uses the CurrentEmployee view.
...however, even though I got this code straight out of their system, I've been personally advised by Acumatica's support team NOT to declare 2 views that use the same primary DAC. Any other suggestions are welcome.