Таблицы Global Temp, созданные в контейнере последовательностей, не сохраняются
Я перемещаю данные с сервера, права доступа к которому у меня ограничены, поэтому я застрял в таблицах ##Temp или одном гигантском скрипте для обработки данных перед их записью на наш главный сервер. Для обработки данных требуется 10 различных запросов. Я могу запустить пять из них одновременно, поэтому помещаю их в контейнер последовательности. Все пять из них создают ##Temps, которые позже используются в основном запросе. Однако... ни один из них не виден после завершения. Если я вытащу их все из контейнера и запущу последовательно по одному... они все сохранятся. Итак, контейнер последовательностей каким-то образом заставляет глобальные временные таблицы удаляться сразу после того, как я их заполняю.
У меня на 100% есть RetainSameConnection = True в моем ConnectionManager.
ChatG предложил, возможно, установить IsolationLevl = ReadUncommitted... не помогло.
Мне не нужно помещать их в контейнер последовательности, но если бы я мог, это было бы более эффективно. И SQL, и Visual Studio — 2019 года. Есть идеи?
Глобальные таблицы ##temp исчезают, когда разрывается последнее (часто единственное) соединение, ссылающееся на них. Почему бы не использовать постоянные таблицы? Если два экземпляра процессов могут работать одновременно, это в любом случае проблема (поскольку они случайно будут совместно использовать таблицу). Если они не могут этого сделать, то постоянная таблица аналогична глобальной таблице ##temp, за исключением того, что она не исчезает.
Я поставил точки останова на событие Post Execute одного или нескольких шагов в контейнере, а затем в SSMS SELECT COUNT(*) FROM ##Temp1 и т. д. SQL жалуется, что они не существуют, а затем следующий шаг, который также их объединяет. терпит неудачу.
Я на государственных серверах. У меня есть полные разрешения на целевом сервере, но ограничены на источнике. Чтобы запросить разрешения на создание, потребовалось бы очень много бюрократической волокиты, и мы, вероятно, не получили бы их. Итак, типа застряли с ##Temp или перенесли все исходные данные, а затем обработали... говорим миллионы или строки.
Вы не можете CREATE TABLE dbo.TableName в tempdb? По крайней мере, это исчезнет только в случае перезапуска сервера.
Ответы 2
RetainSameConnection не поможет, если у вас есть несколько операций, которым требуется одновременный доступ к диспетчеру соединений.
Вы можете создать таблицы в начальной задаче сценария и сохранить открытое соединение в переменной пакета. Это должно поддерживать работу этих глобальных временных таблиц для всех соединений, открытых диспетчером соединений.
Так
- создайте переменную пакета под названием «SqlConnection»
- создайте задачу сценария в своем потоке управления с доступом для чтения/записи к этой переменной
- Откройте SqlConnection и создайте глобальные временные таблицы в задаче сценария, например:
/// </summary>
public void Main()
{
var con = new SqlConnection("Server=localhost;Database=master;Integrated Security=true");
con.Open();
var cmd = con.CreateCommand();
cmd.CommandText = "Create table ##foo(id int, msg varchar(2000))";
cmd.ExecuteNonQuery();
Dts.Variables["User::SqlConnection"].Value = con;
Dts.TaskResult = (int)ScriptResults.Success;
}
- Добавьте еще одну задачу сценария, чтобы закрыть соединение.
- Поместите контейнер последовательности между двумя задачами сценария, и все задачи в контейнере последовательности получат доступ к глобальным временным таблицам.
Это объяснило бы такое поведение. Спасибо! Я изучу это и вернусь к вам.
Большую часть времени я провожу за написанием SQL-скриптов в MS SQL и Databricks. Время от времени я создаю довольно простые пакеты SSIS, используя задачи «Выполнение SQL» для автоматизации некоторых задач MS SQL. В редких случаях я использую объекты потока данных для передачи между серверами. С учетом вышесказанного... мне не помешала бы дополнительная помощь в понимании вашего решения? Создать таблицы вне контейнера последовательностей, а затем просто выполнить INSERT в контейнере? Или вы предлагаете использовать что-то вроде C#, чтобы открыть соединение и отслеживать его состояние с помощью логической переменной?
Хорошо, вы предложили более сложную версию. Пока я ждал, я вручную создал пять таблиц ##Temp в задаче «Выполнение SQL» непосредственно перед контейнером последовательностей, а затем использовал INSERT INTO SELECT вместо SELECT INTO FROM. Все таблицы сохранились в контейнере, и все работает.
Дэвид Браун из Microsoft вдохновил на решение. Его ответ был немного выше моего уровня зарплаты, поэтому я попросил дополнительную помощь. Ожидая его разъяснений, я попробовал то, что, по моему мнению, он имел в виду, и ЭТО СРАБОТАЛО.
Его объяснение имеет смысл и объясняет поведение. Если в одном диспетчере соединений одновременно создается несколько таблиц (например, в контейнере последовательностей, создающем пять таблиц ##Temp), они не сохранятся.
Итак... просто создайте их вручную в объекте «Выполнение SQL» перед контейнером последовательностей и затем заполните их с помощью INSERT INTO SELECT внутри контейнера...
Если по какой-то причине это не сработает... изучите более сложный ответ, который требует использования C# для создания соединений и управления ими через пакет. Убедитесь, что у вас есть код перехвата ошибок, чтобы закрыть их даже в случае ошибки... не нужны утечки.
Огромное спасибо Дэвиду Брауну за помощь... Я потерялся в этом вопросе!
Это всегда мелочи!
Когда вы говорите, что после создания ни один из них не доступен, как вы это определяете? Если вы добавите точку останова после контейнера последовательности, который их создает, оставьте ее активной и выполните запрос к глобальной временной таблице — существует ли она?