Query::Insert_recordset() - выборка из временной таблицы

[Cardagant]

Всем добрый день!

Спрашиваю так как сам решения не нахожу.

Можно ли использовать Query::Insert_recordset() для выборки данных из временной таблицы для вставки их в обычную? Yе нахожу куда в таком случае передаётся курсор временной таблицы, из которой делат ьвыборку.

Заранее спасибо!

UPD: Исходная задача смочь запустить следующий запрос:

            insert_recordset referenceTable (mainTableReferenceField, anotherTableReferenceField)
            select RecId, RefRecId
                from selectedRecords
            notexists join referenceTable
                where referenceTable.(mainTableReferenceField) == callerBaseRecord.RecId
                   && referenceTable.(anotherTableReferenceField) == selectedRecords.RefRecId;

где
mainTableReferenceField и anotherTableReferenceField - известные id полей (переменные типа FieldId) таблицы referenceTable
selectedRecords - временная таблица

[ax_mct]

Цитата:

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

Всем добрый день!

Спрашиваю так как сам решения не нахожу.

Можно ли использовать Query::Insert_recordset() для выборки данных из временной таблицы для вставки их в обычную? Yе нахожу куда в таком случае передаётся курсор временной таблицы, из которой делат ьвыборку.

Заранее спасибо!

UPD: Исходная задача смочь запустить следующий запрос:

            insert_recordset referenceTable (mainTableReferenceField, anotherTableReferenceField)
            select RecId, RefRecId
                from selectedRecords
            notexists join referenceTable
                where referenceTable.(mainTableReferenceField) == callerBaseRecord.RecId
                   && referenceTable.(anotherTableReferenceField) == selectedRecords.RefRecId;

где
mainTableReferenceField и anotherTableReferenceField - известные id полей (переменные типа FieldId) таблицы referenceTable
selectedRecords - временная таблица

Я бы избегал использовать insert_recordset, а также join c временными таблицами, если только не стоит отдельной задачи оптимизации.

У меня к примеру RecId в InMemory таблице в версии 10.0.16 в какой-то момент какая-то корова просто слизывает. Было к примеру 7456, а потом 0.
Все значения пользовательских полей при этом есть. Никаких buf2buf нет.
Даже разбираться нет смысла, просто полагаюсь на свое поле myRecId которое берет значение от RecId после insert.

Клиент не MS будет клеймить, а вас, если в очередной бинарной версии они что-нибудь учудят. А они могут. Там же оптимизировать и оптимизировать

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Так с InMemory временными таблицами (а до DAX2012 просто с временными таблицами) никакой оптимизации и не будет в массовых обработчиках. Только может быть более лаконичный синтаксис, а обработка всё равно будет по каждой записи.

Скорее всего так и есть. InMemory это всего лишь структура в памяти. Но если под insert_recordset мы понимаем "on a single server trip", то потенциально, если захотят, они могут эту одиночную передачу и с временными таблицами реализовать. Вставка идет в SQL таблицу, данные из памяти.

[ax_mct]

Цитата:

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

TempDB-таблицы себя замечательно ведут и замечательно джойнятся. А уж тот факт, что RecId там является счетчиком, который управляется СУБД - вообще достойно уважения. Так что джойны с TempDB-шными таблицами очень даже хороши. Особенно, когда нужно отфильтровать по списку RecId (RecordReferenceList тоже работает - но его потом нужно чистить)

Если мы берем как ответ что вместо InMemory таблицы в insert_recordset можно использовать TempDB-таблицу и это будет замечательно, то пусть это будет как одно из мнений.

Когда в Live/Prod значимого клиента что-то будет отваливаться, примерзать и прочее (а доверия к TempDB никакого) и в процесс нелегкого расследования виноват будет мой код/решение, то отсылки к тому что "это все Microsoft" не будут работать для программистов с больше чем 10 летним опытом именно в этой системе.

Для новичка - может быть, но опыт он как раз про знание проблемных мест и осторожность.

[fed]

Цитата:

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

Когда в Live/Prod значимого клиента что-то будет отваливаться, примерзать и прочее (а доверия к TempDB никакого) и в процесс нелегкого расследования виноват будет мой код/решение, то отсылки к тому что "это все Microsoft" не будут работать для программистов с больше чем 10 летним опытом именно в этой системе.

Для новичка - может быть, но опыт он как раз про знание проблемных мест и осторожность.

Единственная реальная проблема с временными таблицами tempDB(а на самом деле - это ОБЫЧНЫЕ таблицы, просто система их автоматически удаляет) - это возможность засорить sql statement cache. То есть - если у тебя в D365FO стоит такой вот примерно код:
for(i=0;i<10000;i++)
{
myFavoritetempDbTable myTable;
//do something with the table
}
то велика вероятность того, что система создаст 10000 одинаковых временных таблиц с разными именами, потом отправит 10000 разных запросов на вставку и выборку и тп. В результате кэш сиквела затрешиться.
Но от такого антипаттерна легко защититься, добавив еще одно поле для хранения i во временную таблицу, создать только один экземпляр этой временной таблицы и просто во все запросы добавить условие myTable.fieldI == i

А InMemory временные таблицы изначально были достаточно бесполезной штукой. Запросы с их участием обрабатывались на AOS (То есть - из запроса исключалась временная таблица, остатки запроса отправлялись на SQL, оттуда приходил результат - зачастую сотни мегабайт, результат записывался куда-то на AOSовский диск и потом это все медленно и печально джойнилось с inMemory table где-то на дисках AOS). Если просто быстродействия хочется (без необходимости джойнить временную таблицу куда-то), то лучше Map или там List использовать, потому что они в памяти остаются, а не высвопляются на диск AOS если в таблице больше нескольких сотен записей образовалось.

[Raven Melancholic]

Цитата:

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

...Yе нахожу куда в таком случае передаётся курсор временной таблицы, из которой делат ьвыборку.

Я в свое время решения не нашел.
Правда мне нужно было выбирать не из временной таблицы, а из очень даже постоянной, но подготовив курсор (отключить проверку чтения АОС - партнеры зачем-то перекрыли чтение).
Если бы передавался QueryRun, то не было бы проблем. А вот в Query никакой курсор не передашь.

[sukhanchik]

Обсуждение особенностей работы с TempDB-таблицами вынес в отдельную ветку Работа с TempDB-таблицами