i have a simple smart window when has the following instantiated
SDO (customer table), SDV,Smart panel and a smart data browser. The batch size is set to 10 and sorting is done on CustNum.
If viewing the first batch and then adding a new record (say custnum=99) which doesn't lie in the current batch and pressing save, the record that was added is still displayed in the browser even though it doe not belong to the current batch. It is being displayed agin in the browser at the end of every batch.
Please suggest in case im missing a property/attribute. I have also tried indexed-reposition. (files attached for ready reference)
Thanks in advance.
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/bcust.w:550:0]
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/dcustw.i:550:0]
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/dcustw.w:550:0]
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/dcustw_5F00_cl.w:550:0]
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/vcust.w:550:0]
You might not like it. But the behaviour you describe does not surprise me.
The client adds the new row to the view port. I adds a result-list entry for the new row. Everything else would not be acceptable to most users. You want to see it the row has been created or not.
When the server later reads the next batch or an even later batch, it knows nothing about that anymore... So it's query (repositioned by rowid) finds the new row on the server as well. That's why the row might get displayed twice.
I'd log a tech-support call if you want that to be fixed in a future release. I don't think there is a property or merthod you are missing.
The client adds the new row to the view port. I adds
a result-list entry for the new row. Everything else
would not be acceptable to most users. You want to
see it the row has been created or not.
This is one of the more interesting framework "challenges". Making the record disappear silently is generally considered unacceptable, while keeping it also is confusing.
The SDO behavior is also caused by the architecture, as the SDO does not filter data on the client and new records will remain visible.
The DataView, on the other hand, uses a query on the client and reopens on add and the record will disappear, but it will give a warning about the fact that a new record was added outside of the current filter criteria.
My impression is that the most common approach for non adm2/dynamics apps both in ABL and other languages is to keep the record visible and clear the filter and give a warning about the fact that the filter is cleared.
An SDO fix/customization could open a temp query to check for this condition. We just added a new function that converts the server query to a client query called dataQueryStringFromQuery. (I assume it is in 10.1C, but I could be wrong in which case it will be there in 10.2A)
When the server later reads the next batch or an even
later batch, it knows nothing about that anymore...
So it's query (repositioned by rowid) finds the new
row on the server as well. That's why the row might
get displayed twice.
We should have a release note about this behavior. The recommendation (requirement) is that the combination of batching and record create need to be controlled in code. Typically by ensuring that you have the last batch before you add records whose key will end up in the last batch. (There are many alternatives)
I'd log a tech-support call if you want that to be
fixed in a future release. I don't think there is a
property or merthod you are missing.
Correct. It is, however, very unlikely that we will fix the problem with newly added record reoccurring in a batch. It is a result of the SDO architecture and would require extensive changes. (The problem does not exist in the DataView).