Есть самодельная процедура импорта/экспорта базы данных.
При экспорте данных все данные из БД выгружаются в файл. При импорте данных вначале производится очистка БД, затем в таблицы загружаются данные.
Некоторые таблицы содержат identity-столбцы. И с ними проблема.
Если загружать таким способом:
То в такие таблицы данные не загружаются, выдается ошибка многошаговой операции.
Даже если сделать предварительно Connection.Execute "set identity_insert table on", таким способом присвоить столбцу с identity значения не получается.
Тогда я попробовал другой способ, через SQL.
Пишу:
На таблицах с identity выдает ошибку, что присвоить значение столбцу можно только когда identity_insert устновлен в ON. А он должен быть установлен, потому что я Connection.Execute "set identity_insert table on" выполнял.
Если все выполнять в одной строке, т.е.
Тогда работает. Но так мне неудобно, хотелось бы по нормальному (устанавливать identity_insert один раз, перед вставкой всех данных).

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Konst_Oneв одной транзакции все должно работать
Должно, но не работает.
Может где-то неявно задается implicit_transactions.

Kallandorпопробуй сначала организовать временную таблицу.
Хотелось бы обойтись без нее.
Иначе мне придется считывать структуру таблицы, создавать по ней временную таблицу, копировать в нее, переносить в основную. Если получится заставить процедуру работать нормально, это было бы гораздо лучше.

White OwlЕсли ты в любом случае занимаешься полной очисткой таблиц, то я не вижу никаких препятствий к полному убиванию таблицы и пересозданию ее заново.
Через ADO проблематично получить полный DDL таблицы (со всеми ключами, индексами, FK и прочим). Придется либо подключать ADOX, либо это действие выполнять через вставку на T-SQL.

White OwlА вообще, какая база? У большинства серьезных есть встроенные средства блочной заливки данных с правильной обработкой всех дефолтных полей, включая автоинкременты.
MS SQL 2005. И про bcp я знаю.
Но во всех подобных способах файл, с которого осуществляется выгрузка, задается относительно сервера. Т.е. файлы нужно копировать на сервер, после чего запускать загрузку, указывая размещение файлов на самом сервере.
Мне как раз бы хотелось отойти от этого, чтобы пользователям не был нужен файловый доступ к серверу. Т.е. пользователь выбрал файл с данными на своем компе, и тот залился на сервер.
Скорость конечно будет не та, но эта процедура будет выполняться раз в месяц и подождать раз в месяц пять-десять минут будет нормально.
Еще одна причина, по которой используется самодельная процедура импорта/экспорта, а не bcp/bulk insert или backup/restore: 1) на компьютерах пользователей может отсутствовать bcp (у многих пользователей используется MSDE, в который не входят клиентские утилиты) и 2) то, что версии SQL-сервера могут не совпадать, у одних пользователей используется SQL2000, у других SQL2005.

В филиалах работают с программой и раз в месяц высылают свои базы в главную контору.
Сейчас выгрузку осуществляют таким образом: останавливают сервер, архивируют mdf и ldf файлы, высылают в головной офис. Поскольку версии MSSQL разные, постоянно вылезают какие-нибудь неудобства.
Персонал не сильно квалифицированный (что в филиалах, что в головной офисе), поэтому "полуадмина" найти не получится. Поэтому и хочу отделить импорт/экспорт от работы с SQL-сервером.
Если бы был способ через ADO присвоить значение столбцу-счетчику, я был бы счастлив, остальное в принципе готово. Процедура даже работает относительно быстро, порядка 10-15 тысяч записей в секунду.
Но вот если не получится придумать тут что-нибудь путное:
то придется как-нибудь извращаться. Например, добавлять справочники перекодировки, в которых будет хранится соответствие изначального значения счетчика новому значению, и в соответствии с ними перекодировать все данные. Но это сильно коряво и сильно медленно будет.
Хотелось бы найти аналог set identity_insert on для работы через ADO.
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

В этой утилите, которую я делаю, я не хочу слишком уж завязываться на структуру БД. Хотелось бы, чтобы она была максимально независимой от структуры БД; она просто осуществляла перенос данных между двумя произвольными БД одинаковой структуры. За исключением момента со столбцами identity, остальное так и получается.
Если же делать пересоздание таблиц из скрипта, то тогда я буду привязан к конкретной структуре, и при изменении структуры надо будет обновлять утилиту. А я наоборот, хочу максимально облегчить себе работу и не брать на сопровождение дополнительные утилиты.
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Не то, чтобы удалось решить вопрос, но тем не менее что-то стало определенным.
По первому вопросу (добавление через ADO) — похоже не судьба. На сайте MS есть KB253157 , из которого следует, что багу этому уже много лет и исправлять его, похоже, не собираются.
По второму вопросу (добавление через insert) тоже прояснилось, надо было открывать транзакцию, внутри нее identity_insert задается. Т.е. алгоритм такой: Connection.BeginTrans : Connection.Execute "set identity_insert ... on" : Connection.Execute "insert into ... values ..." : Connection.Execute "set identity_insert ... off" : Connection.CommitTrans. Так вроде бы все работает.
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Игорь ГорбоносЕсли все так плохо, тогда почему не рассмотреть вариантна отдельной машине поставить рядом нужные версии MSSQL, этим серверам подкладывать полученные с филиалов mdf и ldf файлы. На центральном сервере настроить Linked Servers и простыми запросами выбирать нужные данные?
Тоже думал об этом. Но нет отдельной машины. Ставить же на клиентские машины не хочу, потому что там каждые две недели заводится зверинец из вирусов, а каждые пару месяцев тамошние админы машины переустанавливают.
Я там админ приходящий и хочу свое присутствие свести к минимуму. Поскольку утилиту написать все же удалось, она подходит больше, чем linked server.