Hi,
just an observation/comment with regard to how locking of datasets seems to be handled.
I saw a case today where some of the same data elements were used in two different, but related datasets. One of these had locking («Expiry days») enabled, the other did not. For those data elements that were part of both data sets, data entry was locked even when entering data for the dataset that was not locked. It took some time (and a suggestion from Ola) before we figured out what was going on.
I’m not sure if this behaviour is by design or not, and I can see both pros and cons of doing it this way. Nonetheless, I found it quite confusing, so I though I’d share it on the list just as a heads up for others.
yes that is the way it is supposed to work at the moment. There are of course arguments on both sides here, but I think its the better solution. If you lock a data set, then you expect that the data will not change, and you could event release reports based on that. If your data changes because someone else has made a data set with the same data elements then it is bad - I think it is better to be on the conservative side here.
Lars
···
On Mon, Jan 20, 2014 at 9:00 PM, Olav Poppe olav.poppe@me.com wrote:
Hi,
just an observation/comment with regard to how locking of datasets seems to be handled.
I saw a case today where some of the same data elements were used in two different, but related datasets. One of these had locking («Expiry days») enabled, the other did not. For those data elements that were part of both data sets, data entry was locked even when entering data for the dataset that was not locked. It took some time (and a suggestion from Ola) before we figured out what was going on.
I’m not sure if this behaviour is by design or not, and I can see both pros and cons of doing it this way. Nonetheless, I found it quite confusing, so I though I’d share it on the list just as a heads up for others.