Я не потерялся, просто немного загружен.
Итак. Про мелочи.
Про моё (не только моё) отношение к управлению транзакциями с клиента я основное сказал. Но есть еще момент. Посылая "BEGIN TRANSACTION" впрямую на сервер мы не учитываем, что некоторые провайдеры (ну и MS SQL тоже, но не в ADO, а в ADO.NET) могут работать в режиме пула соединений. Это прекрасно, что клиент быстро поднимает соединение из пула, вместо "долгого" ожидания создания соединения, но этот механизм сложнее. И глючнее. Т.е. "BEGIN TRANSACTION" гипотетически может уйти не в том соединении, что остальные запросы и "COMMIT", хоть и не в таком тривиальном случае. Нет, конечно, это обычно фиксится (разарботчиком драйвера), но зачем искать грабли, когда у соединения есть методы BeginTrans, CommitTrans и RollbackTrans?
Совсем не понятна конструкция
Conn.Open(); Conn.Execute("BEGIN TRANSACTION"); Conn.Execute(СтрокаЗапроса); CONN.EXECUTE("COMMIT TRANSACTION");
Зачем такие пляски с транзакциями? Нужна транзакция - впихни в запрос. Только если использовать несколько команд в одном запросе, то стоит вначале вставлять "SET NOCOUNT ON;". На самом деле от транзакции тут только лишнее прыгание от 1С в ADO, поэтому проще убрать.
Странное замечание "Следует упомянуть, что для записи в таблицу SQL должны быть права владельца таблицы.". Я могу догадываться, что имелось ввиду (например то, что данному логину предлагается сопоставить пользователя БД со схемой dbo по умолчанию), но право же - неочевидно. Лучше приведите скрипты создания таблиц и логинов - это будет однозначно.
Неаккуратная работа со скобками в куске:
|CONVERT(DateTime,""+Формат(стр.Период), "ДФ = ""YYYY.MM.dd HH:mm:ss""")+""), // и кошерно и работает |"+ ПолучитьGUIDПоУникальномуИдентификатору(стр.Орг.УникальныйИдентификатор()+", |"+ ПолучитьGUIDПоУникальномуИдентификатору(стр.Сцен.УникальныйИдентификатор()+",
Если вам пофигу, что пишете, то как "новичок" сможет разобраться в ваших черновиках?
За что вы СокрЛП на строку натравили? Он же её пообкусает. Ладно справа покусает (там многие кусают и не видно), но ведь и слева покусает!
Странно, что транзакции используются, но при перезаписи (как бы единая операция) удаление происходит в одной транзакции, а вставка в другой. Нипанятна.
Drop table в транзакции в цикле с вопросом, как я писал выше - это ваще жесть. По сути - совершенно однопользовательское решение.
Нужность "архивирования" на этих объёмах тоже вызывает большие сомнения. На таблицах объёмом до 100 ГБ в год кластерного индекса по дате зачастую хватает по уши. А дальше можно использовать секционирование.
Запрос к sysobjects идёт без ограничения типов объектов. А вдруг будет процедура с таким именем?
Если уж коннекты закрываете в конце, то почему рекордсеты не закрывать после использования?
Дальше. У метода Execute соединения и команды вообще-то есть параметры, которые являются битовой маской CommandTypeEnum и ExecuteOptionEnum. В частности есть параметр "adExecuteNoRecords", который рекомендуется для выполнения запросов от которых не ожидается результат. Кстати, для читабельности рекомендую использовать конструкции типа
ExecuteOptionEnum = Новый Структура ("adAsyncExecute, adAsyncFetch, adAsyncFetchNonBlocking, adExecuteNoRecords, adExecuteStream, adOptionUnspecified", 16, 32, 64, 128, 1024, -1);
так можно сделать код очень читаемым и переносимым с VBS.
Пример работы с параметрами можно найти . Вкратце, плюсы: принципиальная невозможность SQL injection, не нужно думать о представлении констант (чисел, дат), однократная компиляция запроса сервером, экономия сетевого трафика. Минус мне известен один: для некоторых типов для очень простых запросов (в частности инсерт узкую в таблицу без индексов) из-за медленной работы на стыке 1С и COM быстрее в 1С собрать нужный скрипт (но тоже надо уметь) и отправить его на сервер.
Блокировочные хинты. По умолчанию MS SQL использует уровень изоляции READ COMMITTED и блокировку по записям (по возможности) с дальнейшей эскалацией по количеству блокировок. Это в целом удобно, но не в случае массовой загрузки. В случае массовой загрузки для экономии памяти лучше заблокировать таблицу целиком до конца транзакции.
Ну а вообще, если интересует производительная загрузка данных, то лучше чутка подтянуть , чтоб воплотить её в практике. А если хочется сделать пример для новичков, а не суперперегрузки то этот пример должен быть безукоризненно красив в своей простоте: он должен быть в едином стиле написания (а не то Conn, то CONN), он должен быть целостным и выполняемым, он должен быть правильным не только с точки зрения новичка, но и с точки зрения нормального программера.
При серверном варианте база данных находится не в файле, а в СУБД на сервере.
Для запроса данных из SQL 1С используются запросы на языке 1С. Они могут быть использованы явно (программист написал в коде программы на языке 1С) или неявно (программист вызывает функцию платформы, которая генерит запрос или такая функция вызывается сама – в форме списка справочника/документа, например).
Сервер 1С транслирует запрос в язык SQL (соответствующую модификацию, поддерживаемую конкретным СУБД) и передает на выполнение в СУБД (SQL 1С).
Кратко о лицензировании различных СУБД
Краткая информация если Вам захочется посмотреть стоимость и в прайс-листах встретятся незнакомые слова:
- Существуют лицензии различных SQL специально для 1С (т.е. «для использования с 1С»)
- Лицензии runtime – купленный SQL можно использовать только с 1С (дешевле)
- Лицензии full-use – купленный SQL можно использовать с разными программами (дороже)
- Существуют лицензии «по количеству процессов сервера» (без ограничения количество работающих пользователей) — PVU
- Существуют комплект лицензий «по сокетам/по клиентам» — LUS
o Одна лицензия на работу SQL на сервере
o Лицензии по количеству сокетов/клиентов (т.е. на 5 соединений, на 10 соединений и т.п.).
Здесь и ниже указана очень только обзорная информация по лицензированию, так как лицензирование у всех СУБД очень сложное, есть разные ситуации, скидки, наличие/отсутствие подписки на ИТС, ограничения и правила «по умолчанию»..
Дополнительно необходимо упомянуть, что СУБД может иметь требования к операционной системе (чтобы она была тоже серверная, например, Windows Server). В варианте MS SQL так и есть, но есть и вариант «обхода» — SQL Developer Edition.
Какие SQL можно использовать с 1С
С 1С можно использовать следующие СУБД:
- Microsoft SQL
Исторически используется чаще всего. Поэтому платформа 1С работает с MS SQL полнофункционально – все типовые конфигурации разработаны именно с прикидкой на нее. - IBM DB2
- Oracle
Включена в поддержку недавно. Имеет особенности. - PostgreSQL
Включена в поддержку недавно. Имеет особенности. Полностью бесплатна (OpenSource), поэтому используется чаще остальных. Также используется в случае установки всего комплекса 1С под Linux.
Рассмотрим особенности использования разных СУБД по очереди.
Перенос баз данных 1С 8.2 из файлового в серверный варианты June 26th, 2013
Все интересные записи перенесены по адресу: http://www.th22.ru/blog/
Ждем вас по новому адресу!
Тут как-бы ничего сложного нет, но инструкцию попросили, посему сделаем.
1. Выгрузка данных происходит в режиме работы 1С "конфигуратор"
. Переходим в пункт "Администрирование -> Выгрузить информационную базу"
.
Указываем каталог и имя файла для выгрузки, после выгрузки получаем файл с расширением .dt (дамп базы средствами 1С в промежуточном формате) который будет использоваться при загрузке данных.
2. Подготавливаем пустую информационную базу на SQL сервере (по поводу именования баз данных тут как говорится на вкус и цвет, но имеет смысл придерживаться определенной логики именования). В среде Microsoft SQL Managment studio нажимаем правой кнопкой на каталоге "Базы данных"
и выбираем пункт "Создать базу данных..."
.
Указываем имя базы данных, владельца, и путь где будут хранится файлы хранилища базы данных.
Нажимаем создать и переходим к следующему пункту.
3. Переходим к серверу 1С предприятия, где в оснастке "Администрирование серверов 1С предприятие"
разворачиваем пункты "Сервер предприятия -> Кластеры -> Информационные базы"
, нажав правой кнопкой мыши на пункте информационные базы в выпадающем меню выбираем пункт "Создать -> Информационная база"
.
Указываем параметры информационной базы:
Имя
- имя которое используется при создании подключения 1С
Описание
- логичное описание базы данных носит исключительно информационный характер
Сервер баз данных
- имя или IP адрес сервера где хранится наша база данных
Тип СУБД
- В нашем случае выбираем MS SQL Server
Пользователь и пароль сервера БД
- Пользователь имеющий права на нашу базу данных
По завершении в список будет добавлена наша информационная база, если получаем ошибку, то проверяем корректность указанных данных.
4. Запускаем 1С предприятие и добавляем созданную нами информационную базу, для чего выбираем пункт "Добавить"
, после чего выбираем "Добавление в список существующей информационной базы"
.
Указываем имя информационный базы, которое может быть уникальным для каждого пользователя, так-как хранится в его профиле, но все-же лучше придерживаться определенной системы именования. Так-же указываем, что база расположена на сервере 1С предприятия.
5. Указываем параметры подключения:
Кластер серверов 1С Предприятия
- Имя или IP-адрес сервера приложений
Имя информационной базы в кластере
- Имя указанное в третьем пункте (В нашем случае аналогичное имени базы данных на сервере MS SQL, хотя может и отличаться)
6. После добавления базы данных в список переходим в режим конфигуратор и аналогично первому пункту выбираем "Администрирование -> Загрузить информационную базу"
, и указываем файл выгруженный в первом пункте.
7. По окончании загрузки конфигуратор будет перезагружен и базой можно пользоваться.
