СЛУЧАЙ №1 (1С: Предприятие 7.7 + SQL Server 2000)
Этот случай возник у меня с одним большим клиентом пару лет назад. У клиента стояла 1С: Предприятие 7.7 + SQL Server 2000 (думаю для 2005 эта проблема останется). Необходимо было взять базу на доработку. Несколько попыток ее выгрузить успехом не увенчались. Выгрузка подвисала и могла висеть всю ночь. Проблема на лицо. База не была такой большой, что бы ей не хватало времени выгрузиться, тем более в связке с SQL Server’ом.
Тестирование и исправление ничего не дало – ошибок «ноль».
Подхожу к решению проблемы следующим образом:
1) Запускаю SQL Server Profiler (так кажется в 2000 он называется) – это монитор выполняемых запросов.
2) Запускаю 1С в режиме конфигуратора и приступаю к выгрузке. Перехожу в Profiler и смотрю на процесс.
3) Замечаю, в определенный момент, в Profiler’e процесс выгрузки останавливается. Т.е. Profiler висит на одном запросе. Жду, возможно, так надо… =514;
4) 20 минут ситуация не меняется – смотрю на текущий выполняемый запрос. Там указание на запрос и на текущую обрабатываемую запись в _1SJOURN. Прерываю выгрузку. Перехожу на эту таблицу, и смотрю, что за запись. Смотрю на реквизиты DATE, DOCNO – это соответственно дата и номер документа, на котором висим! Что за вид документа не смотрю, тупо найду документ с таким же номером в этой дате. BEST!
5) Разбираемся, почему 1С не хочет выгружать именно этот документ. Для этого, собственно, открываем 1С в режиме предприятия, находим этот документ и смотрим на него.
6) Сразу бросается в глаза огромный текстовый блок в этом документе (строка с неограниченной длиной). Все остальное вроде бы в порядке. Мысли такие может из-за того, что слишком большой кусок текста в этом документе. Ловлю себя на мысли, что это бред… Делать нечего, попробую. Очищаю этот реквизит и сохраняю документ.
7) После этого, перехожу к шагу 1 и повторяю процедуру. Ура, злополучный документ проскочил! Но остановились чуть дальше. Все проблема ясна. Но прежде чем очистить реквизит присматриваюсь к тексту и вижу, что в этом тексте полно таблиц построенных с помощью символов псевдографики (тире и прямые слеши). Очищаю и этот реквизит.
8) Продолжаю и так документов пять… Везде эти таблицы с псевдографикой.
9) Выгрузка получена и на последней попытке, время потребовалось не так много оказывается.
ВЫВОД: 1С: Предприятие 7.7 в реквизитах с типом «Строка» с неограниченной длинной на SQLном варианте подвисает, если в этом реквизите много данных с символами ‘-’ и ‘|’. Видимо попадается, какая то последовательность символов, которая не очень «нравится» 1С. Закономерность ясна, но последовательность «корявых» этих символов не установлена.
Клиент доволен. А уж я как доволен ;)
СЛУЧАЙ №2 (1С: Предприятие 7.7 + DBF => 1С: Предприятие 7.7 + SQL Server)
Сделаю небольшое отступление и попытаюсь обрисовать картину с программистами и данной базой, т.к. иначе Вы не поймете всей картины.
На этот раз проблема с DBF базой. У клиента она достигла размеров 3.9 GB (!!!). Это 4 года работы порядка 30-40 одновременно работающих человек! Вы скажете не так много, да согласен, но учтите база то DBF…
Появились проблемы типа, нельзя одновременно открывать 1С в режиме конфигуратора и предприятия (что-то обязательно вылетит), очень медленная скорость работы, постоянные проблемы с переиндексацией. Группа людей, которая занималась этой конфигурацией – или как они позволяют себя называть «программисты» (бывшие военные пред пенсионного возраста(!!!), да и такое бывает), поддерживала и изгалялась над ней, как могла. Там есть документы типа «Выписка», «Выписка1», «Выписка11». Отчеты типа «Отчет для тети Зины». Журналы, которые использовались как подсистемы. Открывание и формирование отчетов, обработок, перепроведение различных документов в тестовой базе выбранных случайно в 70% либо не открываются, либо вылетают с ошибками. В некоторых регистрах по 20 измерений и 15 ресурсов… Перечисления типа такого: «Кладовщики» со значениями «Иванов Иван Иванович», «Петров Петр Петрович» и т.д. это можно продолжать долго.
ЖУТЬ!
От этой базы нужно избавляться, чем скорее, тем лучше, но как? Создание новой конфигурации на восьмерке руководство одобрило. Но за два дня не напишешь конфигурацию, которая закроет потребности целого завода. А руководство требует: «Программа должна взвешивать авто в 1С срочно!». Какое взвешивание? Тут хоть бы завтра конфигурация не загнулась. Ну а так как база DBF-ная, то все работают где? Правильно, на удаленном рабочем столе (терминале), там же база. Попытка провести документ с локального рабочего места происходит за 1.5 минуты. А как взвешивать с удаленки? Внешняя компонента производителя весов может работать только с локалки… Подключение локальных ресурсов не работает как нужно. Ставить Citrix (надстройка над терминалом), решила бы проблему, но это слишком накладно.
Решение было принято следующее: перенести базу на SQL Server. Это избавит от лишних проблем, да и работа с локалки будет по скорости практически одинакова с работой на терминале. Закрыть эту срочную проблему, потом, не спеша, заниматься созданием нормальной конфигурации для предприятия.
Итак, моя задача перенести базу DBF на SQL Server.
Попытаемся определить причины вылетов из конфигурации.
1) Вылеты бывают только тогда когда запущен и конфигуратор и предприятие. На всякий случай. Проверю MD-шник, благо, таких программ много. Программа показала, что в обработке «Шашки» (да, там и такое есть), чего-то там не верно. Заходим, удаляем из конфигурации.
2) Попробую тестирование и исправление. Пробую. Конфигурация выдает больше 1000 ошибок. Скорее всего чудо программисты, никогда не знали, что это такое. Поставил галочку перерасчет итогов, обнаруживаю, что после нее «Оборотно-сальдовая ведомость» не похожа на себя. Значит так делать нельзя. Пересчитывать итоги нельзя! Ужас. Интересно сколько эта база еще выдержит?
3) Попробовать свернуть базу? Да, но есть такие отчеты, причем очень важные, которые нужно формировать именно с 26 марта 2006 года, ни раньше, ни позже, иначе отчета по финансовым результатам не получится. Бегло смотрю, вместо использования регистров или проводок используются перебор документов, ну-ну…
4) Выгружаем базу с DBF. При выгрузке в списке ошибок «Проверка операций. Операция документа ВводОстатковОсновныхСредствНУ 1. Исправлена нумерация проводок;;» таких строк около 100. Лишь бы перенеслось нормально.
5) Потом загружаем на SQL Server. Спустя некоторое время вылетает ошибка: мол в таблице _1SENRTY не может быть создан первичный ключ PK__1SENTRY ввиду повторяющегося значения ключа (200604276PPZLS 2DGY,0,0) и процесс загрузки прекращается. Значит, в таблице _1SENTRY, 1С пытается создать первичный ключ, но за счет того, что записи по которому он строится повторяются он не может быть создан. Исправлять это на SQL смыла нет, так как выгрузка не была завершена, поэтому удалим ее из DBF базы и проделаем все заново.
6) Открываем SQL Server и смотрим на таблицу _1SENTRY. Ага, поле по которому 1С пытается построить первичный ключ называется DATE_TIME_DOCID и состоит из конкатенации DATE (дата проводки), TIME (время проводки) и DOCID (№ документа или операции) + в первичный ключ включается NUMBER (№ проводки) выполняем запрос в базе данных
--Выбирает все проводки, у которых DOCID содержит подстроку «2DGY»
SELECT * FROM _1SENTRY WHERE DOCID LIKE '%2DGY%'
2DGY не случайно именно его нам 1С при загрузке и указала в качестве описания ошибки (см. в пункт 5)
7) Запрос вернул 4 строки с суммами. Причем две строки реально задвоенны! Интересно как это могло получиться в DBF базе? Далее открываем конфигурации в режиме предприятия и ищем ту самую операцию с проводками (Операции>Журнал операций выбираем операции за дату 27.04.2007 – см. пункт 5). По нашим суммам запроса SQL-базы, пытаемся найти задвоенные проводки. После недолгого поиска, наконец, нашел. Открываем документ, которые сделал эти операции, смотрим, там три строки, а вот проводок четыре, хотя по логике больше быть не может! Причем одна явный клон другой и номера у них одинаковые. Пытаюсь перепровести документ, все получается! Лишняя проводка удалилась! Ну, опять. Выгрузка из DBF. Загрузка в SQL… Проскочило. Ура! Если бы такая ситуация повторилась второй раз я планировал написать обработку которая в DВF-варианте перебрала бы повторяющиеся записи и потом по ним пришлось бы перепровести документы. Но мне повезло. Как ни странно, эта ошибка оказалась одной единственной, которая препятствовала выгрузке на SQL Server.
8) Конфигурация полностью перегрузилась. Открываем обе базы SQL и DBF. Открываем оборотно-сальдовую ведомость и по всем фирмам формируем ее. Вроде бы то. Обортки совпадают. Но радоваться рано, проверяю все «работающие» отчеты, все вроде бы сходится.
9) Странное дело, но вылетать после заливки SQL-ный вариант перестал.
Вывод: Конечно, проблема решилась частично: логическая целостность нарушена, итоги накрылись и вряд ли что-то их может оживить, но даже в этом случае на SQL версии, 1С будет работать стабильней. Если не перепроводить документы прошлых периодов и не пересчитывать итоги, база еще немного продержится… А времени для создания новой конфигурации должно хватить с лихвой.
Подчеркну это не свод правил, это моя методика. У кого какие замечания и дополнения прошу к обсуждению
