Сетевые "глюки" 1С
Алексей Жедь
С самого начала должен сделать следующие оговорки:
Не все описанные ниже "глюки" можно с полным правом назвать "глюками" - очень часто глюком называют ситуацию, когда программа ведет себя не так, как хотелось бы пользователю, в то время как с точки зрения разработчика все нормально и корректно. Для простоты далее все такие ситуации будут причислены к "настоящим глюкам".
Не все описанные ниже "глюки" являются следствием ошибок в программах фирмы "1С" - просто на практике они проявляются именно при использовании программ фирмы "1С".
Не все описанные "глюки" имеют непосредственное отношение к сети, однако, как правило, наиболее ярко они проявляются именно при сетевой работе.
Некоторые из описанных "глюков" вообще не имеют отношения к программам фирмы "1С".
Вся информация, изложенная ниже, основана на моем собственном опыте эксплуатации сетевых программных продуктов или на опыте сотрудников нашей компании и ни в какой степени не заимствована из технических рассылок фирмы 1С.
1. Общие положения.
С самого начала следует разделить неполадки, связанные с опознаванием и чтением информации с ключа защиты NetHASP и неполадки, связанные с функционированием собственно программ 1С. Такое разделение абсолютно целесообразно и оправдано т.к. доступ к ключу защиты из программ 1С осуществляется только в момент их запуска. После успешного опознавания ключа и декодирования частей программы ключ становится не нужен. Кто мне не верит, может попробовать запустить программу 1С (здесь и далее я буду просто писать "программа 1С", если не требуется конкретного уточнения, что это за программа) и затем выдернуть ключ. Программа продолжит свою работу и будет работать до тех пор, пока Вы не выйдете из нее (последний раз я проверял это на релизе 8, может быть сейчас что-то изменилось, но это крайне маловероятно). В связи с вышеизложенным я буду разделять все глюки на глюки, связанные с поиском и опознаванием ключа и глюки рабочего режима.
1. Инициализация сервера защиты.
Это пожалуй один из самых "глюконосных" моментов в программах 1С. Начать вероятно следует с самого страшного и необъяснимого.
Если при установке ключа защиты на сервер Windows NT Вы последуете рекомендациям, приведенным в документации по установке, и установите сервер защиты (NetHasp server) в качестве NT-шного сервиса, то может случиться так, что Вы будете сильно удивлены: при перезагрузке NT сервер стабильно переходит в режим "синей смерти", т.е. загрузка не завершается, а на экране монитора на синем фоне возникает какое-то жуткое невразумительное диагностическое сообщение с указанием каких-то адресов. В этой ситуации можно только выразить Вам соболезнование и посоветовать быстренько переустановить NT Server. Нам так и не удалось определить зависимость возникновения такой ситуации от релиза NetHasp server-а - такая штука кажется может происходить с любыми релизами, кроме 13, но прямой связи версии NetHasp Server с релизом нет - в одном и том же релизе, но в разных коробках может попасться NetHasp Server разных версий. Зато нам удалось найти то, с чем не желает спокойно жить NetHaspServer, вызывая этим нежеланием "синюю смерть" - это установленный SAP support. Достаточно убрать из сетевых протоколов SAP support и никакой "синей смерти" больше не возникает. Можно конечно не устанавливать NetHasp Server как NT-шный сервис и запускать его при старте NT любым доступным способом - хоть вручную. Но даже при ручном запуске наличие SAP support продолжает конфликтовать с NetHasp Server-ом - в некоторых случаях NetHasp Server не видит нормально установленный и "живой" протокол NetBios (имеется в виду конечно его эмуляция на IPX), иногда при выключении и последующем включении (без перезагрузки) NetHasp Server вдруг вообще перестает "видеть" установленные сетевые протоколы. В итоге конечно можно подобрать такую комбинацию версии NetHasp Server, способа его запуска и установленных и задействованных на сервере NT сетевых протоколов, что все будет нормально, но как мне кажется, даже в этой ситуации сбои при опознавании ключа возникают чаще. В качестве хохмы могу привести пример, когда нам пришлось написать небольшой BAT-файл, который перезапускался каждые пять минут и вырубал, а затем снова запускал NetHasp Server. Это из-за того, что после каждых 5-7 запусков программы 1С:Торговля на рабочих станциях ключ вдруг переставал опознаваться, а NetHasp Server начинал показываать, что он не видит ни одного из установленных сетевых протоколов. В итоге после сноса SAP support-а все нормализовалось.
Теперь перейдем к следующему глюку. Его в общем-то нельзя назвать сетевым на сто процентов, однако возникает он только в сетевых версиях, когда доступ к ключу осуществляется через NetHasp Server.
Наверное любой из специалистов, поимевших дело с сетевыми версиями программ 1С обратил внимание на возникающую иногда ситуацию, когда после старта NetHasp Server-а первая попытка запуска программы 1С с рабочей станции заканчивается неудачей с сообщением о том, что "…ключ не найден". Однако следующий запуск проходит нормально и все последующие тоже. Хотя иногда вдруг опять программа берет и не запускается. В чем тут дело? По всей вероятности причина заключается в следующем. Ключ защиты - это активное устройство, имеющее в своем составе микрочип. Этот микрочип питается микротоком, который возникает в тот момент, когда в порт LPT (т.е. на ключ) записывают какие-либо данные. До момента первой записи ключ остается не запитанным и соответственно не инициализированным. Вероятно, для инициализации ключа NetHasp Server должен либо бросить туда пустую посылку, а затем уже начать давать "рабочие" посылки, которые требуют ответа ключа, либо после первой посылки сделать паузу перед вычитыванием данных. Мне представляется более вероятным первый вариант. Налицо факт недоработки программного обеспечения NetHasp Server. При встрече с подобным дефектом Вы можете уточнить его характер просто напечатав что-либо на принтере, подключенном к тому же LPT-порту сразу после запуска NetHasp Server-а. Если после этого первый запуск программы 1С с рабочей станции проходит успешно - можете быть уверены - Вы столкнулись именно с вышеописанным дефектом. Если он начинает досаждать Вам, можно попытаться вылечить его заменой LPT-порта - просто подобрать порт, обеспечивающий большую величину микротока (конечно, если LPT-порт интегрирован на материнской плате, то придется поставить дополнительный порт). Программным путем этот дефект можно излечить написанием программки, периодически обращающейся к LPT-порту, однако здесь есть свои трудности - есть вероятность влезть в процесс обмена между NetHasp Server-ом и ключем, так что аппаратный способ мне кажется более приемлемым.
С "левыми" материнскими платами (типа китайских Lucky Star) часто связана неработоспособность нескольких ключей, подключенных к встроенному (на маме) LPT-порту: порт просто не дает необходимой мощности микротока для питания более, чем одного ключа.
2. Принтеры.
Если уж речь зашла об LPT-портах, то невозможно не упомянуть о лазерных принтерах, особенно о принтере HP LaserJet 6L, которые напрочь "сажают" напряжение на ключе и делают его полностью неработоспособным. Выход один - установка дополнительного LPT-порта - больше здесь ничего не поможет. В некоторых случаях принтер просто "подсаживает" LPT-порт и работать на таком порту может только один ключ. На два и более ключа просто не хватает мощности. Есть также некоторые модели принтеров, которые "убивают" ключ, если питание принтера выключить после того, как выключается питание компьютера. Это в первую очередь относится к комбинированным монстрам, объединяющим в себе факс, ксерокс, принтер и т.д. Конечно, не все модели таких устройств столь злобно настроены по отношению к Алладдиновским ключам, но я бы рисковать не стал.
Отдельный разговор о принтерах Lexmark, а вернее о программном обеспечении для них. Речь идет о драйверах этих принтеров. Эти драйвера написаны не программистами, а какими-то абсолютно враждебными существами, категорически недружелюбно настроенными к сетевым принтерам других производителей. Если на компьютере, подключенном к сети болтается такой драйвер (от принтера Lexmark) и в свое время Вы имели неосторожность установить этот принтер, как доступный другим пользователям сети, а потом принтер отключили, но драйвер не снесли, то сколько бы Вы не пытались организовать сетевую печать на принтер другой фирмы, подключенный туда, где раньше жил Lexmark, ничего у Вас не получится - никто из других пользователей сети не сможет напечатать на этом принтере ни слова. Даже снос драйвера Lexmark не всегда помогает: он оставляет какие-то DLL включенными в систему и их приходится либо удалять хирургически, путем долгих и нудных поисков в Registory, либо просто переставлять с нуля Windows. Сами можете представить себе, что будет выделывать ключ NetHasp, включенный в порт компьютера, изгаженного драйверами Lexmark. Выводы: может быть где-то и существуют нормальные драйвера для лазерных принтеров Lexmark, но я таких не встречал. С того момента, как Lexmarkи появились на нашем рынке (3-4 года назад) нам неоднократно приходилось с ними бороться.
Еще о принтерах. Это уже не относится к поиску ключа, а относится к нормальному режиму работы. Однажды мы наткнулись на следующую загадочную ситуацию. Вдруг, ни с того, ни с сего у одного из наших клиентов стали чрезвычайно медленно работать два компьютера из пяти, подключенных к одному хабу (сеть - витая пара пятой категории, 10 Мбит, сервер Novell NetWare 4.11, протокол IPX/SPX). Больно было смотреть, как компьютеры "засыпали" на несколько секунд при листании справочника. Клиент клялся и божился, что с этими компьютерами ничего не делал. После целого дня бесплодных попыток что-то сделать (переустановка и настройка протоколов, драйверов сетевых карт, замена сетевых карт, замена хаба и т.д.) мы обратили внимание на один из оставшихся трех "нормальных" компьютеров этой группы, а вернее на странный лазерный принтер, подключенный к одному из них. Спросили и выяснили, что клиент где-то (ГДЕ???) добыл по случаю лазерный принтер (кажется фирмы NEC), абсолютно новый, но 4-х или 5-ти летней давности выпуска. А с этим принтером на дискете был драйвер только для Windows 3.11. Вот этот драйвер клиент и влепил в Win95. Мы тут же снесли драйвер и к неописуемой радости (своей и клиента) обнаружили, что те два "больные" компьютера заработали как надо - с нормальной скоростью. Драйвер для Win95 мы потом скачали с Интернет, но почему драйвер принтера под 3.11, установленный на одном из компьютеров тормозил два других компьютера (и только их!) я так до сих пор понять не могу.