[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Deleting a record or records in Corticon using ADC

  • Thread starter Thread starter John Miller
  • Start date Start date
Status
Not open for further replies.
J

John Miller

Guest
Hi Branden, I have a couple theories on what is going on, but without a detailed Corticon DEBUG log, I can’t be for sure. First, there is a slight difference between EDC and ADC .remove. Because EDC is completely integrated with Hibernate (Corticon’s bridge technology to a database), when the Rules do a .remove, this Entity instance is removed from Corticon's working memory and also the database. However with ADC, you will need to first remove the instance from the database (using ADC.write Service Callout) and then remove the instance out of Corticon's working memory (using a .remove operator). Order matters in this case. The call to the ADC Service Callout must occur before the Rules do a .remove. ADC bases its operations on Entity instances that are in working memory, so if the Rules do a .remove first, then ADC.write has no instance to work with. Second, there is an issue with your CORTICON_ADC_WRITE_DEF -> SQL value. DELETE FROM cms_ef_error_log WHERE earnings_file_id={CmsEfd.earningsFileId} and attribute_name={Static.attributeName} You are pulling variables from two different Entity types … CmsEtd and Static. ADC.write explicitly checks for this condition and creates a Rule Message stating that this is a problem and stops processing. There are many reasons why we prohibit the use of different Entity Attributes inside the WHERE clause. One main issue is that it would add complexity to the feature which could confuse the user. Even though, in your case, there is only 1 instance of Static in memory, there is no guarantee that this will always be the case. Imagine that there are 2 or 3 instances of Static in memory, with each one having a different “attributeName” value. The paradigm of each PRIMARY_ENTITY instance representing 1 row in the database falls apart. The easiest work-around is to add the Static.attributeName value to the CmsEtd Entity through a Transient Variable. Here are the steps: 1) Create CmsEtd.tempAttributeName as a Transient inside the Vocabulary. 2) Create a new Rulesheet which will copy over the Static.attributeName value into the CmsEtd.tempAttributeName. 3) Update the CORTICON_ADC_WRITE_DEF -> SQL value to : DELETE FROM cms_ef_error_log WHERE earnings_file_id={CmsEfd.earningsFileId} and attribute_name={CmsEfd.tempAttributeName} Now, the SQL only contains Attributes from Entity CmsEtd. And lastly to address your ADC and EDC question from last posting, it isn't advisable to mix and match ADC and EDC in the same Vocabulary. You are correct that there could be continuity and synchronization issues. Some Entity instances would be managed by EDC (Hibernate) while other would be managed by ADC. It can be done, but only in specific cases. I hope this helps. Regards, John

Continue reading...
 
Status
Not open for further replies.
Back
Top