Влияние selectLocked(false) на возвращаемый курсор

[Sergey Petrov]

Добрый день, коллеги!

Столкнулись с непонятным.
Имеем запись в SalesTable и поле в ней (поле добавленное, не из стандарта).
Визуально:
- Смотрим через обозреватель таблицы - видим значение в поле.
- Смотрим через форму - видим значение в поле.
- Смотрим через "Паспорт записи" - видим значение в поле.
В коде:
- Ищем запись через SalesTable::findRecId() - видим значение поля.
- Ищем запись через SalesTable::find() - не видим значение поля.

Раскопки привели к тому, что SalesTable::findRecId() не использует salesTable.selectLocked(). То есть, используется значение по-умолчанию (true). А вот SalesTable::find() использует, причём выставляет этот флаг равным false.
Имитация на уровне запроса SQL напрямую с NOLOCK и без этой инструкции всегда возвращают корректное значение поля (как и ожидается).

Кто-нибудь сталкивался в подобными странностями? И как их обойти?

А традиционные чистки кэшей и перезапуски аосов не помогают?

[Logger]

Похоже кеширование влияет. Рассинхронизация кеша и реальных данных.
Когда вы ищете SalesTable::find() то идет запрос по первичному ключу и в ax3.0 должно сработать кеширование.
Во всех остальных случаях оно не работает.

Попробуйте еще у полученного буфера вызвать
info(strFMT(' SalesTable.wasCached() = %1 ', SalesTable.wasCached()));

он вам покажет был ли использован кеш и какой вид кеша использовался.
можно также вырубить кеш SalesTable.disableCache(true)
прямо перед запросом и посмотреть результат.

[Sergey Petrov]

Коллеги, спасибо за оперативный совет! find() действительно берёт курсор из кэша, а findRecId() - напрямую.