Работа с TempDB-таблицами

[Logger]

Крайне неприятный баг.
Использованные вами методы работают со ссылкой на переменную. Возможно из-за этого дополнительные зависимости появляются и поэтому падает.

А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

Там просто реальное SQL имя таблички передается.
Возможно не будет падать.
Я в своей модификации использовал их - не падало. Правда сценарий был немного другой.

[fed]

Цитата:

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

Крайне неприятный баг.
...
А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

Я на эту тему думал, но мы решили, что это все равно настроечная форма, которой в месяц раз пять пользуются. Соответственно - пять мусорных временных табличек в месяц - это дешевле чем эксперименты, которые иногда сервер роняют. (При этом о том, что AOS от этой функциональности иногда падает, мы знали с февраля примерно, но комбинацию данных, при которой это железно происходит - выловили только неделю назад).

[bio_unit]

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

delete_from tmpSomeTable;

Видимо, когда сборщик мусора отрабатывает, то tmpSomeTable может ссылать на какой-то произвольный курсор, какой-то случайной таблицы и delete_from отрабатывает по какой-то произвольной физической таблице БД.
Например, в одном случае - CustParameters, в другом - InventTable.
Из таблиц БД начинают "загадочно" пропадать данные.

[Logger]

Цитата:

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

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

А как лечили ?

Убирали

delete_from tmpSomeTable;

Отказались от dispose ?