Skip to main content
Solved

Is there any difference between Base.ViewName.AllowUpdate = true and Base.ViewName.Cache.AllowUpdate = true


aaghaei
Captain II
Forum|alt.badge.img+10

Hello All,

Does anyone know what is the difference between “Base.ViewName.AllowUpdate = true” and “Base.ViewName.Cache.AllowUpdate = true”?

My understanding from the Acumatica resources is the former is a shorter form of the latter. I have been using the short form forever and haven’t had any issues so far. I recently came across a weird situation in RowSelected event I am setting AllowEdit = true in the short form but when I trace I see the AllowEdit is still false RANDOMLY when this line of code is executed resulting in the line being read-only. I spent 4:30 tracing and chasing ghosts and finally, I just thought let's use the long form and surprisingly it is working.

The funny thing is I have two Grids in the form and of course, each is tied to a view. One of them works just fine without any issues but the other one is acting up. The only difference between these two views is the one which is acting up has a view delegate while the other one is just a simple public view.

Does anyone have any idea why this is happening?

 

Best answer by davidnavasardyan

Hi @aaghaei 

`Base.ViewName.AllowUpdate = true` and `Base.ViewName.Cache.AllowUpdate = true` are actually not identical.

The `AllowUpdate`, `AllowDelete`, and `AllowInsert` properties of a `PXSelect` view in a graph (such as `Base.ViewName.AllowUpdate`) control the user interface behavior related to the specific view. This means they control whether the user is able to edit, insert, or delete records from the grid or form tied to that view. If you set `Base.ViewName.AllowUpdate = false`, the user won't be able to edit records in the grid/form tied to that view.

On the other hand, `Base.ViewName.Cache.AllowUpdate` or `Base.ViewName.Cache.AllowDelete` or `Base.ViewName.Cache.AllowInsert` are affecting the DAC Cache, controlling whether it's possible to perform the Insert, Update, or Delete operations on the cache level for a particular DAC tied to the view. This impacts whether or not these operations can occur programmatically within the code.

If `AllowUpdate` is set to `false` for a cache, you can't update that cache's data even if you tried to do it from a graph extension or another graph.

That's why it is recommended to use `Base.ViewName.AllowUpdate` (or `AllowDelete`/`AllowInsert`) for most cases since it directly influences the behavior of the form or grid. But in some cases, when you want to control the programmatically Insert, Update, or Delete operations for a particular DAC, you should use `Base.ViewName.Cache.AllowUpdate` (or `AllowDelete`/`AllowInsert`).

In your specific case, there could be many reasons why one form is behaving differently from the other. It could be due to the way the views are defined, the attributes set on the fields, or the order of execution of event handlers and view delegates. Without having a detailed look at your code and understanding your use case, it's hard to pinpoint the exact reason. But understanding the distinction between `AllowUpdate` for views and caches might help you troubleshoot the issue.

View original
Did this topic help you find an answer to your question?

3 replies

aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • July 15, 2023

Update, I see Acumatica’s in its own source codes also use the short form often and long form occasionally.


davidnavasardyan
Jr Varsity I
Forum|alt.badge.img+2

Hi @aaghaei 

`Base.ViewName.AllowUpdate = true` and `Base.ViewName.Cache.AllowUpdate = true` are actually not identical.

The `AllowUpdate`, `AllowDelete`, and `AllowInsert` properties of a `PXSelect` view in a graph (such as `Base.ViewName.AllowUpdate`) control the user interface behavior related to the specific view. This means they control whether the user is able to edit, insert, or delete records from the grid or form tied to that view. If you set `Base.ViewName.AllowUpdate = false`, the user won't be able to edit records in the grid/form tied to that view.

On the other hand, `Base.ViewName.Cache.AllowUpdate` or `Base.ViewName.Cache.AllowDelete` or `Base.ViewName.Cache.AllowInsert` are affecting the DAC Cache, controlling whether it's possible to perform the Insert, Update, or Delete operations on the cache level for a particular DAC tied to the view. This impacts whether or not these operations can occur programmatically within the code.

If `AllowUpdate` is set to `false` for a cache, you can't update that cache's data even if you tried to do it from a graph extension or another graph.

That's why it is recommended to use `Base.ViewName.AllowUpdate` (or `AllowDelete`/`AllowInsert`) for most cases since it directly influences the behavior of the form or grid. But in some cases, when you want to control the programmatically Insert, Update, or Delete operations for a particular DAC, you should use `Base.ViewName.Cache.AllowUpdate` (or `AllowDelete`/`AllowInsert`).

In your specific case, there could be many reasons why one form is behaving differently from the other. It could be due to the way the views are defined, the attributes set on the fields, or the order of execution of event handlers and view delegates. Without having a detailed look at your code and understanding your use case, it's hard to pinpoint the exact reason. But understanding the distinction between `AllowUpdate` for views and caches might help you troubleshoot the issue.


aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • July 17, 2023

@davidnavasardyan09 thank you for taking the time and the thorough explanation. The issue I am .Cache.AllowUpdate works but the Problem is the issue was happening RANDOMLY. If it was because of extensions priority, view/DAC properties, then it should’ve had a consistent pattern. If Cache Update was somehow disabled it should have impact on all documents at the same state and record/field statuses. I spent quite a few hours to see what happens that causes this random behavior but couldn’t pin point it.

Again, thank you for the explanation.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings