View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003091 | 10000-011: Historical Access | Spec | public | 2015-06-09 16:00 | 2015-07-21 17:59 |
| Reporter | Jim Luth | Assigned To | Rod Stein | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 1.03 | ||||
| Summary | 0003091: OperationLimitsType - MaxNodesPerHistoryUpdateXxx issues | ||||
| Description | The description of MaxNodesPerHistoryUpdateData and MaxNodesPerHistoryUpdateEvents refers to historyReadDetails but this is a parameter of HistoryRead and not present in HistoryUpdate. The HistoryUpdate has just a list of extension objects in the historyUpdateDetails where a detail contains a NodeId and an array of data or events. Events and data can be mixed. The current description makes no sense and in the way like defined, it also makes no sense to have two independent parameters. | ||||
| Additional Information | 6.3.11 OperationLimitsType The MaxNodesPerHistoryUpdateData Property indicates the maximum size of the historyUpdateDetails array supported by the Server when a Client calls the HistoryUpdate Service using historyReadDetails RAW, PROCESSED, MODIFIED or ATTIME. The MaxNodesPerHistoryUpdateEvents Property indicates the maximum size of the historyUpdateDetails array when a Client calls the HistoryUpdate Service using historyReadDetails EVENTS. | ||||
| Tags | No tags attached. | ||||
| Commit Version | |||||
| Fix Due Date | |||||
| related to | 0003058 | closed | Wolfgang Mahnke | 10000-005: Information Model | OperationLimitsType - MaxNodesPerHistoryUpdateXxx issues |
|
|
Part 5 fixed some incorrect text, but Part 11 should describe best practices for client (e.g. not mix events and data so the Max properties make sense.) |
|
|
Fixed in 1.03 draft 03 ... If the HistoryUpdate Service is called with both DataValues and Events in the same call the Server operational limits MaxNodesPerHistoryUpdateData and MaxNodesPerHistoryUpdateEvents (See UA Part 5) may be ignored. The Server may return a service result code Bad_TooManyOperations if it is not able to handle the combination of DataValues and Events. It is recommended to call the HistoryUpdate Service twice, once with DataValues and then with Events. |
|
|
Text in doc reviewed and accepted in telecon. Not closed yet pending:
|
|
|
Agreed to changes in telecon. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-09 16:00 | Jim Luth | New Issue | |
| 2015-06-09 16:00 | Jim Luth | Status | new => assigned |
| 2015-06-09 16:00 | Jim Luth | Assigned To | => Wolfgang Mahnke |
| 2015-06-09 16:00 | Jim Luth | Issue generated from: 0003058 | |
| 2015-06-09 16:00 | Jim Luth | Relationship added | related to 0003058 |
| 2015-06-09 16:01 | Jim Luth | Project | 10000-005: Information Model => 10000-011: Historical Access |
| 2015-06-09 16:02 | Jim Luth | Assigned To | Wolfgang Mahnke => Rod Stein |
| 2015-06-09 16:05 | Jim Luth | Note Added: 0006113 | |
| 2015-06-10 20:58 | Rod Stein | Note Added: 0006124 | |
| 2015-06-10 20:58 | Rod Stein | Status | assigned => resolved |
| 2015-06-10 20:58 | Rod Stein | Fixed in Version | => 1.03 |
| 2015-06-10 20:58 | Rod Stein | Resolution | open => fixed |
| 2015-06-23 15:58 | Jim Luth | Note Added: 0006173 | |
| 2015-07-21 17:59 | Jim Luth | Note Added: 0006253 | |
| 2015-07-21 17:59 | Jim Luth | Status | resolved => closed |
