Kashperuk Ivan: Tutorial: refresh, reread, research, executeQuery - which one to use?

[Perc]

formDataSource.reread()
formDataSource.research()

не всегда ошибка.
В ситуации

      for(tmp = custTrans_DS.getFirst(1) ? custTrans_DS.getFirst(1) : custTrans;
            tmp; tmp = custTrans_DS.getNext() )
        {
            tmp.selectForUpdate(true);
            tmp.reread();
            tmp.Amount = 100;

            tmp.update();
        }
        
        custTrans_DS.reread(); 
        custTrans_DS.research();

и большом количестве выделенных записей (через ctrl + A) в форме мне помог только reread. Видимо когда getNext начинает грузить в кэш, текущий курсор вдруг решает что ему надо сохраниться и research сначала сохраняет устаревший буфер. А потом честно загружает все с БД.

[S.Kuskov]

Цитата:

Сообщение от Perc

research сначала сохраняет устаревший буфер

А может это из-за того что какое-то значение в текущей строке под курсором было изменено пользователем ещё до выполнения обновлений в цикле, но не было сохранено в БД. Т.е. строка источника данных перешла в состояния редактирования. Тогда описываемое вами поведение объясняется тем, что research вызывает потерю фокуса на текущей строке, что в свою очередь вызывает сохранение ранее изменённых но ещё не сохранённых и уже не актуальных данных.

Хотя при такой последовательности действии наверное должна возникнуть ошибка вроде "Данные уже были изменены другим пользователем ..." или что-то в таком духе

[Perc]

Цитата:

Сообщение от S.Kuskov

А может это из-за того что какое-то значение в текущей строке под курсором было изменено пользователем ещё до выполнения обновлений в цикле, но не было сохранено в БД. Т.е. строка источника данных перешла в состояния редактирования. Тогда описываемое вами поведение объясняется тем, что research вызывает потерю фокуса на текущей строке, что в свою очередь вызывает сохранение ранее изменённых но ещё не сохранённых и уже не актуальных данных.

Хотя при такой последовательности действии наверное должна возникнуть ошибка вроде "Данные уже были изменены другим пользователем ..." или что-то в таком духе

нет, запись пользователь не менял.
Проблемы нет если выделенных строк не много или выделили их не через "ctrl + A", а по честному все - т.е. shift+мышь, ctrl+мышь или встать на первую запись потом нажать shift+ctrl+end. Т.е. когда все изменяемые записи попали в кэш до запуска перебора. Получается когда подгружается кэш, текущий курсор помечается как обновленный. Вот стэк вызовов где происходит write текущего курсора

[c] \Forms\PriceDiscAdm\Data Sources\PriceDiscAdmTrans\Methods\write 3
[c] \Classes\FormDataSource\leaveRecord
[c] \Classes\FormDataSource\executeQuery
[c] \Classes\FormDataSource\research
[c] \Classes\FormButtonControl\Clicked 51
[c] \Classes\FormMenuButtonControl\Clicked

[S.Kuskov]

Цитата:

Сообщение от Perc

Т.е. когда все изменяемые записи попали в кэш до запуска перебора.

А попробуйте в getFirst передать вторым параметром true
https://msdn.microsoft.com/en-us/lib...(v=ax.10).aspx

Цитата:

fetchAhead
A Boolean with a default value of true.
If false, only cached records are returned. If true, additional records are found and added to the cache.

[Perc]

Цитата:

Сообщение от S.Kuskov

А попробуйте в getFirst передать вторым параметром true
https://msdn.microsoft.com/en-us/lib...(v=ax.10).aspx

getFirst(1, true) работает так как и описано в документации. true по умолчанию, перебираются все выделенные записи; false - только те видимо, что были в кэше на момент нажатия ctrl+a. Спортивного интереса ради проверил быстро - в моем случае штук 30. Логично что при false проблема с обновлением текущей записи исчезает