А.Я. Архангельский: 100 компонентов общего назначения библиотеки Delphi 5. Эта книга — вторая в серии, посвященной Delphi — популярной среди разработчиков системе визуального объектно-ориентированного проектирования прикладных программ для Windows. Delphi — превосходный инструмент, с помощью которого и начинающий пользователь, и программист-профессионал могут создавать одинаково профессионально выглядящий интерфейс пользователя к прикладным программам самых различных классов.
В данной книге описаны компоненты библиотеки Delphi 5. Описание скомпоновано не по страницам библиотеки, а по назначению компонентов и по выполняемым ими функциям. Это позволяет параллельно рассматривать сходные компоненты, сравнивать их возможности и давать рекомендации по их применению.
Описаны также некоторые классы и типы Delphi 5, которые формально не являются компонентами, поскольку не включены в палитру библиотеки, но без которых изложение было бы неполным. Например, невозможно описывать компоненты отображения графической информации, не рассмотрев канву Canvas, перо Pen, кисть Brush. А такие объекты, как принтер Printer, приложение Application или экран Screen, фактически являются невизуальными компонентами и не включены в страницы библиотеки только потому, что в каждой прикладной программе они имеются всего в одном экземпляре.
К сожалению, в небольшой книге невозможно описать все компоненты библиотеки. Поэтому пришлось пойти на самоограничение — отказаться от описания компонентов, предназначенных для работы с базами данных и с Интернет. Применение этих компонентов связано со спецификой соответствующих прикладных программ, которая требует отдельного и детального рассмотрения. Эти компоненты будут описаны в будущих книгах серии «Все о Delphi».
Данная книга предназначена для пользователей различной квалификации – от начинающих до опытных специалистов. Начинающий найдет в ней простое изложение методики работы с различными компонентами. Специально для этой категории читателей введена небольшая первая глава и отдельные разделы второй главы, поясняющие общие принципы работы с Delphi 5. А опытному пользователю она также будет полезна как справочное пособие. Во-первых, он найдет в ней сведения по последней версии Delphi — Delphi 5, в которой появилось много нового. А во-вторых, жизнь показывает, что обычно даже опытный разработчик предпочитает работать с очень ограниченным набором когда-то освоенных им компонентов и не использует в полной мере всего богатства библиотеки Delphi.
Книга написана так, что ее отдельные главы и разделы можно читать в произвольном порядке. Вероятно, наиболее разумно сначала проглядеть ее всю, не вникая в детали, посмотреть краткие характеристики отдельных групп компонентов и иллюстрирующие их рисунки, возможно, построить некоторые описанные в книге тестовые приложения, чтобы воочию увидеть функционирование компонентов. А потом по мере работы с Delphi 5, когда возникают те или иные задачи и проблемы, обращаться к соответствующим главам и разделам как к справочному пособию за более детальной информацией.
От Автора:
У читателя, знакомого с моими большими (и, увы, дорогими) книгами по аналогичной тематике, например, с книгой «Программирование в Delphi 4», может возникнуть законный вопрос: «Как соотносится материал той книги и этой, не является ли данная книга просто фрагментом большой?». Смею заверить, что не является. Конечно, часть материала повторяется. Но, прежде всего, книга посвящена Delphi 5 и в нее введен соответствующий материал по этой новой версии Delphi. Да и по традиционным компонентам материал заметно расширен по сравнению с соответствующими разделами книги «Программирование в Delphi 4». В книгу добавлено описание ряда компонентов (компонентов ActiveX, фреймов, Application, ApplicationEvents), многие компоненты (например, списки) рассмотрены существенно более детально, введено много новых примеров. Так что данную книгу можно рассматривать как значительно расширенное и переработанное издание соответствующих разделов прежней книги.
Чтобы упростить ориентирование во все более разрастающемся Интернете, была разработана система DNS (Domain Name System - система именования доменов сети). Дело в том, что каждому компьютеру или компьютерной сети, подключенной к Интернету, назначается уникальная последовательность цифр, называемая IP-адресом.
IP-адрес состоит из четырех чисел, от 0 до 255 каждое, например 198.105.232.001. Зная IP-адрес, пользователь одного компьютера с легкостью находит другой компьютер в Интернете, и может к нему подключиться, если у него есть на это соответствующие права. Все просто, когда вам нужно получать доступ к одному-двум компьютерам, но если их количество переваливает за десяток или даже за сотню, а, тем более, если вам необходимо сообщать определенный IP-адрес многим людям, ситуация становится поистине кошмарной.
Избавиться от подобных проблем помогает система имен DNS. Она позволяет заменять цифровые IP-адреса на благозвучные буквенные, например: «microsoft.com» или «yandex.ru». Как же работает DNS? Все Интернет-пространство можно разделить на несколько групп, называемых «доменными зонами». Эти зоны называются доменами первого уровня. Разделение по зонам может проводиться как по географическому, так и по тематическому признаку. Географическая доменная зона определяет расположение компьютера в том или ином государстве. Вот несколько примеров географических доменов первого уровня: ru - Россия, fr - Франция, uk - Великобритания, jp - Япония, su - бывший Советский Союз. Тематические доменные зоны группируют компьютеры по информации, содержащейся на них, либо по типу организаций, ими владеющих, вне зависимости от их географического расположения.
Два компьютера, зарегистрированные в одной тематической доменной зоне, могут находиться в противоположных концах земного шара. Вот примеры тематических доменных зон: com - коммерческое предприятие, net - что-то связанное с сетевыми технологиями, edu - образовательное учреждение, info - информационный проект, gov - государственное учреждение, biz - бизнес-проект, mil - военная организация. Несмотря на обилие доменных зон, далеко не все из них пользуются большой популярностью. Основная часть компьютеров в Интернете зарегистрирована в доменных зонах com и net. Некоторые доменные зоны используются и вовсе не по прямому назначению. Например, островное государство Тувалу стало обладателем географической доменной зоны tv, которую сейчас облюбовали организации, так или иначе связанные с телевидением: телеканалы, производители бытовой техники, киноделы, рекламщики и прочие...
Каждая доменная зона делится на поддомены, или домены второго уровня, и каждому из этих поддоменов присваивается свое имя, например совпадающее с названием организации, владеющей доменом. Это имя приписывается к имени домена верхнего уровня слева, в виде суффикса, и отделяется точкой. Например, в имени microsoft.com строка com означает доменную зону, а суффикс microsoft - имя домена второго уровня. Как нетрудно догадаться, по этому адресу находится сеть, принадлежащая корпорации Microsoft. Однако сеть корпорации Microsoft весьма велика, поэтому каждый домен второго уровня, в свою очередь, может делиться еще на несколько подподдоменов, или доменов третьего уровня. Это записывается так - mail.microsoft.com. В этом примере mail - это суффикс домена третьего уровня. Такое деление может продолжаться до бесконечности, но обычно ограничивается доменами третьего-четвертого уровня.
Общее руководство и контроль над доменными зонами, осуществляет организация ICANN (The Internet Corporation for Assigned Names and Number - Интернет-ассоциация по выдаче имен и чисел). Она передает полномочия на выдачу адресов в той или иной доменной зоне другим организациям и следит за соблюдением основных правил. Организации, уполномоченные выдавать доменные адреса в той или иной доменной зоне, торгуют доменными адресами второго уровня. То есть, если кто-то хочет, чтобы у его компьютера в Интернет был адрес vasya-pupkin.com, он должен обратиться к организации, выдающей доменные имена в зоне com. Затем попросить зарегистрировать в ней домен второго уровня vasya-pupkin, предоставить IP-адрес своего компьютера в Сети и, разумеется, уплатить некоторую сумму денег. В результате, компьютер Васи в Интернете можно будет отыскать не только по малопонятному набору цифр IP-адреса, но и по звучному текстовому адресу.
При желании, одному IP-адресу можно сопоставить даже несколько доменных имен, например vasya-pupkin.com и vasiliy.ru. Адреса в Российской доменной зоне выдает организации РосНИИРОС, Российский НИИ развития общественных сетей.
Современный Интернет представляет собой сложнейшую систему из тысяч компьютерных сетей, объединенных между собой. Состоит эта система из двух основных элементов: узлов сети Интернет и соединяющих их информационных магистралей. Узлом Интернета называют любое устройство, имеющее свой IP-адрес и подключенное к Сети. Несмотря на кажущуюся мешанину межкомпыотерных соединений и отсутствие централизованного руководства, Интернет имеет определенную иерархическую структуру.
В самом низу иерархии находится многочисленная армия конечных пользователей. Часто не имеющие даже постоянного IP-адреса подключаются к Интернету по низкоскоростным каналам. Тем не менее, пользователи являются одними из основных потребителей услуг Сети и главными «спонсорами» коммерческой части Интернета. Причем на одного «физического» пользователя, т. е. реального человека, пользующегося услугами Сети, может приходиться несколько пользователей «логических», т. е. различных подключений к Интернету.
Так, кроме компьютера, возможность подключения к Интернету может иметь мобильный телефон, карманный компьютер, бытовая техника, автомобиль и даже кондиционер. Конечные пользователи подключаются к компьютерам Интернет-провайдера, или, как их еще называют, ISP (Internet Service Provider - провайдер Интернет). ISP - это организация, основная деятельность которой связана с предоставлением услуг Интернета пользователям.
У провайдера есть своя компьютерная сеть, размеры которой могут варьироваться от сотен десятков узлов в нескольких городах до многих тысяч, раскиданных по целому континенту. Эта сеть называется магистральной сетью, или бэкбоном (от слова backbone - стержень, магистраль). Сети отдельных провайдеров соединяются между собой и другими сетями. Среди ISP есть «монстры», которые обеспечивают соединение между собой сетей различных стран и континентов, являясь своего рода «провайдерами для провайдеров». Весь этот конгломерат компьютерных сетей и образует то, что называется Интернетом.
Особняком стоят DNS-серверы - компьютеры, отвечающие за функционирование системы DNS. Для подключения конечных пользователей к ISP служат так называемые «точки доступа» - компьютеры или специальные устройства, содержащие оборудование для подключения «извне».
Подключившись к точке доступа провайдера, пользователь становится частью магистральной сети провайдера и, соответственно, получает доступ к ее ресурсам, а также к ресурсам сетей, соединенных с бэкбоном провайдера, т. е. ко всему Интернету. Кроме конечных пользователей, к сети провайдеров подключаются различного рода серверы, или «хосты» (от слова host - хозяин). Это узлы сети, на которых работает программное обеспечение, обеспечивающее практически все услуги, предоставляемые сетью Интернет.
В данной статье приведены общие сведения об организации работы системы 1С:Предприятие с распределенной информационной базой (ИБ). Также описаны внутренние особенности организации механизма работы с распределенными данными для того, чтобы специалисты, осуществляющие конфигурирование и администрирование распределенных систем могли лучшее понимать выполняемые системой действия. Данная информация может также быть использована для оценки дополнительных затрат ресурсов системы, расходуемых на поддержание распределенной информационной базы.
Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.
Назначение и основные принципы
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Содержимое информационных баз синхронизируется путем переноса измененных объектов данных между каждой из периферийных и центральной ИБ. Для переноса данных используются так называемые файлы переноса данных. Перенос изменений выполняется только между центральной и периферийными ИБ. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Однако, для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ, имели заведомо непересекающиеся пространства номеров, кодов и т. п., может потребоваться внести в конфигурацию некоторые изменения. Также изменения в конфигурации должны вноситься при необходимости обеспечить специальные ограничения работы пользователей на периферийных информационных базах.
Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).
Регистрация изменений
Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:
константа,
элемент справочника,
документ,
календарь,
счет бухгалтерского учета,
типовая операция.
Вместе с документами переносятся все действия, выполняемые ими в процессе проведения: движения регистров, акты расчета, бухгалтерская операция, проводки. В случае, если при проведении документа производятся изменения периодических реквизитов элемента справочника, то производится перенос всего элемента справочника.
Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().
Регистрация изменений ведущих объектов производится в специальной служебной таблице. При этом фиксируются следующие данные об изменении объекта:
Сам ведущий объект;
Идентификатор той ИБ, в которую должно быть передано изменение;
Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.
Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.
Выгрузка и загрузка изменений
Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.
Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.
В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.
При загрузке файла переноса данных помимо загрузки измененных данных выполняется так называемый прием подтверждений.
В случае, когда пришло подтверждение на получение выгрузки, содержащей последнее изменение объекта, запись об изменении удаляется из таблицы регистрации. То есть записи об изменении объектов данных хранятся в таблице регистрации до тех пор, пока не будет получено подтверждение о доставке измененного объекта по назначению.
Причем выгрузка измененного объекта будет производиться до тех пор, пока не будет получено подтверждение, о доставке изменения. Это значит, что если выполнять перенос все время в одном направлении и не выполнять обратного переноса то объем файла переноса данных будет все время расти, так как каждый раз будут передаваться все объекты, измененные после последнего полученного подтверждения.
При загрузке изменений объектов из периферийной ИБ в центральную, в таблицу регистрации изменений (если, конечно, параметры миграции настроены соответствующим образом) заносятся записи, указывающие, что загруженные из периферийной ИБ изменения объектов должны быть переданы в другие периферийные ИБ.
Изменения конфигурации
Как уже отмечалось, при работе с распределенной ИБ, конфигурация системы может быть изменена только в центральном узле.
Для регистрации изменений конфигурации и передачи ее на периферийные ИБ используется тот же механизм, что и для объектов данных. При записи измененной конфигурации, в таблицу регистрации изменений объектов по числу известных периферийных ИБ заносятся записи, фиксирующие факт изменения конфигурации.
После записи измененной конфигурации в распределенной ИБ складывается такая ситуация, что центральная и периферийные ИБ работают фактически с разными конфигурациями. В таком состоянии созданные на периферийной ИБ файлы переноса данных не могут быть загружены на центральной ИБ по той причине, что в условиях различных конфигураций содержащаяся в файле информация не может быть правильно интерпретирована. Обмен будет восстановлен только после того, как в периферийную ИБ будет загружена измененная конфигурация с центральной ИБ. То есть после изменения конфигурации требуется выполнить перенос из центральной ИБ в каждую из периферийных, а уже затем выполнять перенос из периферийных ИБ в центр.
Перенос измененной конфигурации в периферийные ИБ осуществляется тем же способом, что и перенос измененных объектов данных. В процессе очередной выгрузки из центральной ИБ, в файл переноса данных целиком включается измененная конфигурация, если, конечно, в таблице регистрации изменений содержится запись о том, что измененную конфигурацию следует передать в соответствующую периферийную ИБ. Выгрузка конфигурации также будет производиться до получения извещения о приеме измененной конфигурации.
Заметим, что конфигурация считается измененной при любых изменениях метаданных, форм, модулей, таблиц конфигурации, наборов прав, пользовательских интерфейсов, описаний. В состав конфигурации не входит список пользователей, а также внешние по отношению к файлу конфигурации (1CV7.MD) файлы (внешние отчеты, отдельно записанные таблицы и тексты). И эти внешние файлы не переносятся механизмом управления распределенной ИБ. Поэтому при конфигурировании распределенной системы не рекомендуется использовать в конфигурации находящиеся в отдельных файлах модули, таблицы и отчеты.
Для изменения уже работающей конфигурации можно рекомендовать использовать механизм загрузки измененной конфигурации. Он позволяет специалисту скопировать конфигурацию, выполнить в ней все необходимые изменения, отладить внесенные изменения (этот процесс может занять и несколько дней), а затем загрузить измененную конфигурацию в центральную ИБ, после чего изменения будут распространены на все периферийные ИБ с очередной передачей изменений. Такая последовательность позволит избежать многократной передачи измененной конфигурации в периферийные ИБ в процессе ее модернизации.
При загрузке файла переноса данных на периферийной ИБ, этап загрузки измененной конфигурации (если, конечно, она содержится в файле переноса данных) предшествует этапу загрузки измененных объектов данных. В случае неудачного завершения загрузки конфигурации, загрузка объектов данных производиться не будет и информационная база останется в том же состоянии, что и была до начала загрузки.
Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии. Приведем описание действий системы в наиболее типовых вариантах коллизий.
Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.
Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.
Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом, управление распределенной информационной базой имеет определенную стратегию автоматического разрешения любых коллизий с описанными приоритетами. Однако, в реальных условиях рекомендуется средствами конфигурации определить возможные действия пользователей на различных узлах таким образом, чтобы исключить или минимизировать вероятность возникновения коллизий. Основным путем является определения средствами конфигурации "ответственного" узла за каждый ведущий объект в распределенной ИБ и ограничение всем остальным возможности его редактирования и удаления. Определение "ответственных" должно происходить исходя из логики работы предприятия. Очевидно, что многие виды объектов можно разрешить изменять только в центральной ИБ (например, список складов). Для многих объектов можно рекомендовать средствами встроенного языка установить возможность изменения только на той ИБ, на которой они созданы, например для документов.
Параметры миграции
С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:
Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.
Место создания. Данный вариант настройки также является довольно простым. В этом случае изменения объекта не передаются в другие ИБ. При такой настройке параметров миграции, объект данного вида никогда не "покидает" места своего создания и не появляется в других ИБ. Однако при выборе данного варианта следует учитывать возможные ссылки на объекты данного вида из объектов других видов, имеющих другие параметры миграции. Например, если установить такой вариант для справочника, и в документах, которые участвуют в обмене, будет содержаться реквизит типа справочник данного вида, то при переносе документа получится неразрешенная ссылка.
Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.
В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.
В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.
Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".
Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.
При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.
Наиболее простой случай - это смена любого из вариантов области распространения на вариант "Место создания". В этом случае из таблицы регистрации изменений удаляются все записи по данному виду объектов. То есть все изменения объектов, еще не переданные в другие ИБ, не будут переданы. При этом, все объекты для которых данная ИБ не является местом создания, не будут удалены. Просто их изменения (как и изменения других объектов данного вида) не будут больше передаваться в другие ИБ.
Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.
При изменении области распространения объектов с "Место создания и центр" на "Все информационные базы", какие-либо действия предпринимаются только в центральной ИБ. В этом случае определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. После этого производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи состояния объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Проблемы конфигурирования и администрирования
При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.
Очевидной проблемой, которая уже упоминалась выше, является уникальная и последовательная нумерация документов и элементов справочников. Для организации уникальной нумерации используется механизм префиксов. Для его включения в конфигурацию, прежде всего, следует выработать некоторую дисциплину, зависимости префикса от ИБ, в которой создается объект. В простейшем случае это может быть собственно код ИБ. Однако часто префикс может автоматически определяться на каждой ИБ, но не являться ее кодом, так как он может участвовать в печатных формах документов и должен быть понятным для пользователей системы. Более сложной задачей является обеспечение сквозной нумерации объектов без префиксов в случае, когда такая нумерация регламентируется нормативными документами. Особенно сложным является обеспечение строго последовательной нумерации. Очевидно, что полного решения данной проблемы не может быть в принципе, так как объекты создаваемые динамически в независимых системах не могут иметь строгой сквозной нумерации. Отчасти данная проблема решается с помощью введения диапазонов номеров, выделяемых для каждой ИБ. Следует заметить, что номера документов и коды справочников не являются внутренними идентификаторами и их уникальность для системы не обязательна. Это значит, что поддержку уникальность номеров и кодов можно отключить для тех видов, объектов, для которых она не нужна. Кроме того, средствами конфигурации можно организовать перенумерацию объектов, например в центральной ИБ. Однако следует иметь ввиду, что эти изменения будут передаваться как и любые другие изменения, что может вызвать достаточно большой объем передаваемых между узлами данных.
Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.
Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.
Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.
В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.
В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.
Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".
Формат PDF был разработан фирмой Adobe Systems, чтобы решить проблему единства отображения и обработки полиграфической продукции в различных информационных средах (его кроссплатформенность) и довольно успешно справляется с этой задачей и по сегодняшний день. Однако со временем у этого формата появилось и иное предназначение. Универсальность этого формата спровоцировала рост его популярности, а, следовательно, увеличилось и количество публикаций, доступных в этом формате в электронном виде в Интернете.
Изначально файлы формата PDF в сознании многих людей ассоциировались именно с качественным уникальным контентом, т. к. с его помощью часто публиковались и публикуются различные отчёты, доклады, статьи, руководства и другая полезная информация. Конечно, было бы глупо упускать такой источник полезной информации. Со временем все популярные поисковые системы научились индексировать файлы PDF и ранжировать их, что автоматически поставило их наравне с привычными для нас файлами в формате HTML (веб-страницами).
Нам же важно не упустить возможную выгоду и научиться правильно оптимизировать файлы подобного рода для поисковых систем, чтобы обеспечить их лучшую видимость в результатах поиска. Долгое время файлы PDF воспринимались исключительно как файлы-архивы, для открытия которых необходимо было их загружать на компьютер и читать в сторонней программе (Например, в Adobe Reader – программе для просмотра формата PDF). Так было раньше, сейчас же многое меняется: значительно увеличиваются скорости Интернета, появляются встроенные в браузер плагины для чтения формата PDF, позволяющие просматривать файлы сразу же в браузере. Например, уже сегодня в браузере Opera можно читать файлы PDF прямо на сайте онлайн. А это всё прямое свидетельство того, что популярность этого формата в обозримом будущем будет только расти. Это теперь не только универсальный формат для хранения и редактирования полиграфии, но также и способ передачи информации в Интернете (выполняющий функции обычной веб-страницы).
В этой статье я старался систематизировать информацию, осветив как можно больше фактов, влияющих на индексацию поисковыми системами документов этого формата в Интернете, а также ответив на самые распространённые вопросы, которые возникают у веб-мастеров, использующих эти файлы на своих сайтах.
Любой веб-мастер и seo-оптимизатор должен понимать, что файл PDF - это такая же страница сайта, как и файл в формате HTML. Как правило, на этот файл ссылаются так, что он является тупиковым для поисковой системы, т. к. в нём почти никогда не содержатся ссылки на другие страницы сайта, а зря. Каждый PDF-файл (как и страница HTML) находится в индексе поисковых систем, следовательно, имеет и свой поисковый вес, передаваемый по ссылкам (вИЦ или PR, если хотите). Я настоятельно рекомендую вам в любом файле PDF, выложенным на сайте, делать ссылки на обычные HTML-страницы сайта и на другие страницы PDF (можно даже продублировать навигацию основного сайта). В данном случае вы будете только в выигрышном положении, т. к. помимо передачи поискового веса по ссылке, посетитель, скачав файл PDF с вашего сайта и ознакомившись с информацией в нём, может к вам вернуться, щёлкнув по ссылке, ведущей на ваш сайт из скачанного документа. К тому же файл PDF редко редактируется, поэтому часто сохраняется в первоначальном виде, а также как файловый архив может стремительно распространяться через различные файловые хостинги, а это, опять же, новые пользователи для вашего сайта (тот редкий случай, когда поисковая оптимизация напрямую влияет на непоисковое продвижение).
ПРОГРАММЫ ДЛЯ РАБОТЫ С ФАЙЛАМИ PDF
Для создания файлов PDF используйте программу Adobe Acrobat, т. к. она имеет целый арсенал средств, которые способны максимально качественно оптимизировать наши файлы. Несмотря на это, можно (но не рекомендуется) использовать и другие программы. Например, для создания файлов PDF вы можете использовать связку программ Adobe Pagemaker и Adobe InDesign или текстовые редакторы наподобие Word из пакета Microsoft Office или Write - из OpenOffice. Когда будете использовать текстовый редактор Word для создания документа формата PDF, то используйте теги H1, H2, H3 и другие подобные для оптимизации текста документа. Вы должны сделать полученный текст базирующимся на языке HTML, чтобы поисковые системы эффективно его индексировали.
Не используйте программы типа Photoshop и Illustrator, т. к. после обработки документа на выходе информация превращается в одно большое изображение, текст на котором не распознать поисковым системам. Однако часто случается и то, что у веб-мастера уже есть большое количество PDF-файлов, полученных от заказчика, или же специфика темы на сайте такая, что по ней есть информация в электронном виде только в этом формате. Если у вас именно такой случай, то не отчаивайтесь. Сейчас активно разрабатываются программы, способные распознавать текст на изображениях, что позволяет модифицировать текст на изображениях в обычный текст, который индексируется поисковыми системами. В России довольно успешно распознаванием текстов занимается компания ABYY. К примеру, вы можете воспользоваться их конвертером Abbyy PDF Transformer. Хочу сразу заметить, что это довольно уникальный продукт, аналогов которому почти нет. В его возможности входит конвертирование текста на картинках PDF в текст, способный индексироваться поисковыми системами.
Несколько слов, я думаю, можно сказать и про программы конвертеры. Если же вы решили, что по каким-то причинам формат PDF на сайте вас не очень устраивает, а контент вашего сайта состоит, в основном, из файлов PDF, то у вас есть возможность переконвертировать эти файлы в формат HTML, используя различные бесплатные и платные PDF конвертеры.
Вот небольшой список таких конвертеров:
* Advanced PDF to HTML
* Comfortable PDF to HTML
* Easy PDF to HTML
* Adobe Acrobat Pro Extended – это конвертер компании Adobe, но известно, что оптимизаторы испытывают сложности с этой программой.
Теперь, я думаю, самое время поделиться с вами секретами оптимизации файла PDF для поисковых систем.
ИЗОБРАЖЕНИЯ
Не используйте слишком много изображений или изображения большого размера. Картинки хоть и улучшают внешний вид, однако также увеличивается размер файла и время его загрузки. Как и на HTML-странице, если вы поставите много изображений (особенно неоптимизированных), то это потребует больше времени для их загрузки в браузер. Но помимо оптимизации размера изображений PDF-документа, необходимо также оптимизировать и подписи (альтернативный текст) к ним. У каждого изображения документа должна быть своя подпись, как к картинкам обычной HTML-страницы.
РАЗМЕР ФАЙЛА
Нужно всегда помнить, что поисковые системы не индексируют файлы, которые слишком много весят. Например, поисковая система "Яндекс" не будет индексировать файлы весом больше, чем 10 Мб, отсюда следует правило, что файл PDF не может быть больше 10 Мб.
Если говорить про оптимальный размер PDF-файла, то многие seo-оптимизаторы считают его величину в пределах 500 - 1000 Кб, т. к. с файлами именно таких размеров происходит меньше всего ошибок, связанных с индексацией файлов.
Для оптимизации размера в программе Adobe Acrobat есть специальная функция: Advanced > PDF Optimizer.
Внимание! При создании PDF-документа в любом редакторе обращайте внимание на версию получаемого файла. Рекомендуемая версия – 1.5 и ниже, т. к. такой файл гарантированно будет читаться всеми программами для просмотра PDF и роботами поисковых систем. Формат PDF позволяет оптимизировать также и копию документа, поэтому по возможности оптимизируйте и её.
ТЕКСТ ФАЙЛА
Старайтесь избегать большого количества текста в одном файле PDF, дробите один файл на несколько файлов, причём, линкуйте их ссылками внутри каждого такого документа (так, как бы вы это делали с обычными HTML-документами).
Оптимизируйте текст файла PDF под конкретные ключевые запросы, а здесь надо уделять внимание таким же показателям, как и на обычной веб-странице (плотность ключевых слов не выше 5% и прочим). Если вы хотите получить хорошо индексируемый и релевантный поисковым запросам контент PDF-документа, вы должны стараться избегать нагромождения страниц в нём. При внутренней оптимизации текста, а именно: заголовков и подзаголовков, ключевых слов и фраз, необходимых для вашего документа, - будьте очень осторожны, чтобы файл не выглядел заспамленным и не вылетел, в итоге, из индекса поисковых систем.
Если ваш файл PDF разбит на несколько частей, то настройте порядок отображения этих частей. От порядка чтения документа зависит то, какая информация будет предоставлена поисковому роботу сначала, а какая - потом. Помните, что наибольшую поисковую значимость имеют ключевые слова, находящиеся ближе к началу документа, поэтому если в документе обратное, то вам стоит перестроить логическую последовательность частей вашего PDF документа, чтобы выделить наиболее важные части и улучшить их поисковую видимость в Интернете.
Сделайте оглавление (поисковую карту документа), каждый пункт этого оглавления оформите ссылкой (закладкой) внутри PDF документа, для каждой ссылки пропишите ключевые слова в описании ссылки. Этот приём наиболее эффективен для документов, состоящих из нескольких логический частей и с большим количеством страниц – он обеспечивает качественную внутреннюю перелинковку документа, позволяющую эффективно индексировать документ поисковым роботам.
Если вы хотите создать справочник, руководство или другой документ, предполагающий большой объём информации в одном файле, то я рекомендую создавать подобные документы в формате DjVu. Страницы документов (контент) в этом формате не индексируются поисковыми системами. Но если по каким-то причинам у вас не получается уменьшить размер PDF-файлов и разбить их на несколько отдельных файлов, то можно воспользоваться очень удобной функцией в программе Adobe Reader - Optimize for Fast Web View, позволяющей просматривать уже загрузившиеся страницы документа, не дожидаясь его окончательной загрузки. Это удобно для тех пользователей, кто будет просматривать ваш PDF-файл непосредственно на вашем сайте в режиме онлайн.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ (МЕТАПОЛЯ)
Очень важно заполнить всю дополнительную информацию о вашем файле PDF. Уделите особое внимание таким тегам как: Title (заголовок), Author (автор материала), Subject (тема), Keywords (ключевые слова документа), Descriptions (описание PDF-документа) и Copyright (авторские права). Все эти настройки можно найти в программе Adobe Acrobat в меню File > Document Properties. Метаданные файла PDF имеют схожее происхождение с метатегами файлов HTML, так что уделяйте им особое внимание при оптимизации.
КОДИРОВКА, ШРИФТЫ И РАСПОЛОЖЕНИЕ ФАЙЛА
Несколько слов нужно сказать и про оптимизацию шрифтов. Не забывайте включать в сам файл все необходимые (нестандартные) шрифты. Довольно часто для декоративных целей используются самые разнообразные и редкие полиграфические шрифты, которые могут плохо восприниматься поисковыми системами, поэтому, по возможности, старайтесь пользоваться стандартными шрифтами (Arial, Helvetica, Sans-Serif, Times New Roman и другими), которые хорошо индексируются поисковыми системами. Их плюс в том, что они присутствуют по умолчанию в любой операционной системе, поэтому из документа PDF их можно спокойно исключить, уменьшив тем самым размер файла.
Шрифты, которые не были добавлены в PDF-документ или отсутствуют в операционной системе, будут отображаться тем шрифтом, который имеется (самым близким по значению), что может привести к нежелательным последствиям, а именно к увеличению или уменьшению числа страниц, количества символов в строках, межстрочного интервала и других проблем метрики.
Довольно болезненный параметр для поисковых систем - кодировка файла. Если поисковая система не сумеет определить кодировку вашего PDF файла самостоятельно, то документ вообще не будет проиндексирован, поэтому всегда проверяйте, указана ли она. Желательно использовать самые известные и популярные кодировки.
Ваш файл PDF, как и обычная страница файла, должен быть максимально близок к корню сайта. Ссылайтесь на них ближе к главной странице, не пытайтесь засунуть его глубоко в структуру сайта, чтобы не понизить поисковую значимость вашего PDF документа.
Не давайте вашим документам в формате PDF слишком сложные имена. Упрощайте их. Несколько слов в названии самого файла разделяйте символом "_". Например: imya_documenta.pdf. Также для разделителя можно использовать и символ "-", но я рекомендую использовать первый вариант.
После всех проделанных операций по оптимизации можете выкладывать файл на сайт. Поисковые системы найдут файл, проиндексируют его и начнут выводить в результатах поиска, и если материал интересен, начнётся самораскрутка его среди посетителей - на файл начнут ссылаться, скачивать и публиковать его в других местах (а сам файл будет с ссылками на ваш сайт). Неплохо, не правда ли?
Напоследок, предоставлю вам пару ссылок, которые могут быть полезны в связи с опубликованным материалом:
http://ru.wikipedia.org/wiki/PDF - общая информация о файле PDF
http://get.adobe.com/reader/ - последняя версия Adobe Reader
http://www.adobe.com/products/acrobat/ - последняя версия Adobe Acrobat
http://www.abbyy.ru/pdftransformer/ - последняя версия Abbyy PDF Transformer
http://www.taurion.ru/acrobat - самоучитель работы в программе Adobe Acrobat
В этом обзоре я постарался ответить на наиболее распространённые вопросы по оптимизации файла PDF, которые задают люди, занимающиеся раскруткой сайтов. Но если у вас появились вопросы или что-то осталось непонятным, то, пожалуйста, сообщайте об этом! Буду рад любым отзывам от вас! Спасибо!
В этой статье описываются полезные функции и процедуры, помогающие эффективно работать с различными типами данных в системе "1С:Предприятие 7.7".
* Обработка значений
* Форматирование
* Список значений
* Таблица значений
* Таблица
* Период и дата
* Календари и праздники
* Справочники
* Документы
* Предопределённые функции
* Налоговый учёт
Обработка значений в 1С
Форматирование данных в 1С
Список значений в 1С
Таблица значений в 1С
Таблица или печатная форма в 1С
Периоды и даты в 1С
Календари и праздники в 1С
Справочники в 1С
Документы в 1С
Предопределённые функции и процедуры в 1С
Налоговый учёт и первое событие в 1С
Резюме
В статье описаны функции и процедуры, используемые в программе "1С:Предприятие 7.7" для работы со справочниками, документами, списками значений, таблицами значений и с прочими агрегатными типами данных. Образцы практического применения описанных средств Вы сможете найти в статьях "Отчёты для 1С" и "Обработки для 1С".
В данной статье рассмотрены принципы, помогающие компилятору Delphi генерировать более оптимальный с точки зрения скорости код. Если Вы не хотите вникать в подробности, в конце статьи есть «свод правил», которые рекомендуется соблюдать при написании программ.
Компилятор Delphi относится к разряду оптимизирующих. Но насколько качественно проводится оптимизация? Как «помочь» компилятору создать более быстрый код? Давайте разберемся с этим на экспериментах.
Оптимизация константных выражений
Пример 1:
С точки зрения оптимизации код можно упростить еще на этапе компиляции до
Но написанный выше листинг преобразуется в
С одной стороны компилятор не «сообразил», что значение переменной «a» можно преобразовать в константу и сложить с другой константой (которая, заметим, подставлена именно как константа) на этапе компиляции, с другой стороны был применен весьма хитрый трюк с LEA (об этом ниже). Тем не менее, код
в любом случае быстрее и короче.
Пример 2:
Скомпилированный код будет выглядеть
А ведь значение, присвоенной переменной «а» являлось константой и наш пример можно было бы переписать как:
Пример 3:
После компиляции получаем:
Т.е. компилятор преобразовал код так, как он был написан, а ведь можно было бы просто записать:
Оптимизация алгебраических выражений
Пример 4:
После компиляции эти переменные будут удалены, причем с предупреждением
Пример 5:
Код скомпилируется как есть! Таким образом мы обманули компилятор псевдо использованием переменных. Delphi не исправляет нашей «кривости», поэтому эта задача ложится исключительно на плечи программиста.
Пример 6:
Данный код можно оптимизировать до
И этого Delphi за нас не сделает.
Пример 7:
В данном примере первую строчку можно безболезненно удалить, что Delphi делать умеет.
Пример 8:
В данном случае можно избавится от одной операции умножения, присвоив значение выражения a*b временной переменной. Анализ ассемблерного листинга показывает, что компилятор именно так и поступает. Тем не менее, поменяв второе подвыражение на ((b*a)>0), компилятор принимает выражения за разные и генерирует умножение для обоих случаев, не смотря на то, что результат одинаков.
Оптимизация арифметических операций
Сложение и вычитание
Применение инструкции LEA вместо ADD позволяет производить сумму 3х операндов (двух переменных и одной константы) за один такт. Трюк заключается в том представление ближних указателей эквивалентно их фактическому значению, поэтому результат, возвращенный LEA равен сумме ее операндов. При возможности Delphi производит такую замену.
Деление
Операция деления требует гораздо больше тактов процессора, нежели умножение, поэтому замена деления на умножение может значительно ускорить работу. Существуют формулы, позволяющие выполнять такое преобразование. Тем не менее, Delphi не использует такую оптимизацию. Деление на степень двойки можно заменять сдвигом вправо на n бит, но даже в этом случае получаем следующий код:
Здесь учитывается особенность самой операции div – округление в большую сторону. Поэтому, если можно пренебрегать округлением, используйте c:=a shr 1 вместо с:=a div 2.
Умножение
Умножение на степень двойки можно заменять сдвигами битов. Delphi заменяет умножение сдвигами при умножении на 4,8,16 итд. При умножении на 2 производится суммированием переменной с собой.
Умножать на 3,5,6,7,8,10 и т. д. можно и без операции умножения – расписав выражение по формуле (a shl n)+a, где n – показатель степени двойки. Например, при умножении на 3 n=1. Delphi при возможности прибегает к этому трюку. Заметим, операнд LEA умеет умножать регистр на 2,4,8, что также при возможности используется компилятором. Например, умножение на 3 преобразуется в инструкцию
Оптимизация case of
Анализ скомпилированного кода показывает, что Delphi проводит утрамбовку дерева. Т.е. значения case сортируются и выбор нужного элемента производится при помощи двоичного поиска.
В случае, если элементы case of выстраиваются в арифметической прогрессии, компилятор формирует таблицу переходов. Т.е. создается массив указателей с индексами элементов, поэтому выбор нужно элемента выполняется за одну итерацию независимо от количества элементов.
Оптимизация циклов
Разворачивание циклов – не производится. Разворачивание циклов весьма спорный момент в оптимизации, поэтому принять грамотное решение может только человек. Delphi не производит разворачивания ни больших, ни маленьких циклов.
Слияние циклов – не производится. Если два цикла, следующие друг за другом имеют одинаковые границы итерационной переменной, разумно оба цикла объединить в один.
Вынесение инвариантного кода за пределы цикла – не выносится. Наиболее распространенный недочет – условие цикла записывается как:
Delphi будет при каждой итерации вызывать метод count, вычитать из результата 1 и потом уже сверять. Настоятельно рекомендуется переписывать подобный код как
Весь код VCL написан с нарушением этого правила. Очевидно, что проще подобного рода оптимизацию встроить в компилятор, нежели переписывать VCL :)
Замена циклов с предусловием на циклы с постусловием – производится. Циклы с постусловием имеют главное преимущество над другими видами циклов (с предусловием и с условием в середине) – они содержат всего одно ветвление. Delphi производит такую замену.
Замена инкремента на декремент – не производится. Более того, даже декрементный цикл компилируется в неоптимальный код, т.к. не используется флаг ZF. Вместо этого происходит сравнивание значения регистра с 0.
Удаление ветвлений – не производится.
Вывод:
1. Не используйте переменные для временного хранения констант или обязательно объявляйте «магические» числа как const, либо подставляйте в код непосредственные значения
2. Неиспользуемыми объявлениями и присвоениями можно безболезненно пренебрегать – Delphi умеет их вычищать.
3. Внимательно следите за использованием переменных, в частности лишним присвоениям их значений друг другу. Такого рода оптимизации Delphi делать не умеет.
4. Используйте свернутые математические выражения. (например, (3*a - a) /2 упрощается до a). Delphi не умеет упрощать математические выражения. (Да и что говорить, даже MathCAD не всегда грамотно умеет делать такие преобразования).
5. Не используйте конструкции типа a:=10*sin(45*pi/180); Delphi не вычислит эту константу на этапе компиляции, напротив, будет послушно вызывать sin и pi по ходу выполнения программы! В случае, если угол является переменной, по крайней мере pi можно заменить константой 3,1415...
6. Delphi прекрасно справляется с выражениями, полностью составленных из констант – они вычисляются на этапе компиляции.
7. Внимательно следите за условиями и их границами. Компилятор Delphi не умеет обнаруживать заведомо ложных условий. Также он не умеет удалять заведомо лишние условия. Например, (a>0) and (a<15616) and (a<>0)
8. Если в условии несколько раз проверяется одно и тоже выражение, следите, чтобы оно было выражено во всех конструкциях одинаково. В противном случае скомпилированный код будет не оптимален. Например, if ((a*b)>0) and ((a*b)<1024) then... При перестановке во втором случае b*a смысл выражения не изменится, но код будет иметь уже на одну операцию умножения, а две. Можно временно присвоить проверяемое выражение временной переменной, а затем уже проверять полученное значение.
9. Сообщение «Combining signed and unsigned types – widened both operands» сообщает не только о потенциальной ошибке – также вследствие преобразования мы теряем производительность. Например, z – объявлена как ineteger. условие if z>$abcd6123 then z:= $abcd6123; несмотря на его правильность вызовет данное предупреждение. Сгенерированный код будет, выполнять преобразования величин до 64-х бит, и дальнейшее уже сравнение 64-х битных операндов. Если изменить тип z на cardinal, мы избавимся от предупреждения и получим 3 строки кода, вместо 8 !
10. Delphi умеет оптимизировать сложение, умножение и частично деление. При делении на степень двойки, если не важно округление до большего, рекомендуется пользоваться shr 1 вместо div 2.
11. В case of при возможности используйте элементы, расположенные в арифметической прогрессии. Тем не менее, даже при невыполнении данного условия мы получим качественный код после утрамбовки дерева.
12. Выносите инвариантный код за тело цикла. Наиболее частая ошибка – for i:=1 to length(str) do... Дело в том, что при каждой итерации будет вызываться функция length, что пагубно скажется на производительности. Рекомендуется длину строки заранее присвоить переменной. Также не включайте в тело цикла код, заведомо не зависящий от изменения итерационной переменной.
Сравнивая Delphi с компиляторами Visual C++, WATCOM, Borland C++ (тестирование данных компиляторов приведено в [1]) приходим к выводу, что Delphi по своим оптимизирующим свойствам аналогичен Borland C++ (а кто сомневался? ;) ). Учитывая, что Borland C++ по итогам сравнения оказался последним, делаем несложный вывод. Весьма печален и тот факт, что большинство кода VCL написано с точки зрения «красоты» кода, а не его оптимальности с точки зрения скорости. Например, не соблюдается правило 12.
Чаще всего аналоговое кодирование используется при передаче информации по каналу с узкой полосой пропускания, например, по телефонным линиям в глобальных сетях. Кроме того, аналоговое кодирование применяется в радиоканалах, что позволяет обеспечивать связь между многими пользователями одновременно.
Код RZ
Код RZ (Return to Zero – с возвратом к нулю) – этот трехуровневый код получил такое название потому, что после значащего уровня сигнала в первой половине битового интервала следует возврат к некоему "нулевому", среднему уровню (например, к нулевому потенциалу). Переход к нему происходит в середине каждого битового интервала. Логическому нулю, таким образом, соответствует положительный импульс, логической единице – отрицательный (или наоборот) в первой половине битового интервала.
В центре битового интервала всегда есть переход сигнала (положительный или отрицательный), следовательно, из этого кода приемник легко может выделить синхроимпульс (строб). Возможна временная привязка не только к началу пакета, как в случае кода NRZ, но и к каждому отдельному биту, поэтому потери синхронизации не произойдет при любой длине пакета.
Еще одно важное достоинство кода RZ – простая временная привязка приема, как к началу последовательности, так и к ее концу. Приемник просто должен анализировать, есть изменение уровня сигнала в течение битового интервала или нет. Первый битовый интервал без изменения уровня сигнала соответствует окончанию принимаемой последовательности бит (рис. 3.12). Поэтому в коде RZ можно использовать передачу последовательностями переменной длины.
Определение начала и конца приема при коде RZ
Рис. 3.12. Определение начала и конца приема при коде RZ
Недостаток кода RZ состоит в том, что для него требуется вдвое большая полоса пропускания канала при той же скорости передачи по сравнению с NRZ (так как здесь на один битовый интервал приходится два изменения уровня сигнала). Например, для скорости передачи информации 10 Мбит/с требуется пропускная способность линии связи 10 МГц, а не 5 МГц, как при коде NRZ (рис. 3.13).
Скорость передачи и пропускная способность при коде RZ
Рис. 3.13. Скорость передачи и пропускная способность при коде RZ
Другой важный недостаток – наличие трех уровней, что всегда усложняет аппаратуру как передатчика, так и приемника.
Код RZ применяется не только в сетях на основе электрического кабеля, но и в оптоволоконных сетях. Правда, в них не существует положительных и отрицательных уровней сигнала, поэтому используется три следующие уровня: отсутствие света, "средний" свет, "сильный" свет. Это очень удобно: даже когда нет передачи информации, свет все равно присутствует, что позволяет легко определить целостность оптоволоконной линии связи без дополнительных мер (рис. 3.14).
Использование кода RZ в оптоволоконных сетях
Рис. 3.14. Использование кода RZ в оптоволоконных сетях
Манчестерский код
Манчестерский код (или код Манчестер-II) получил наибольшее распространение в локальных сетях. Он также относится к самосинхронизирующимся кодам, но в отличие от RZ имеет не три, а всего два уровня, что способствует его лучшей помехозащищенности и упрощению приемных и передающих узлов. Логическому нулю соответствует положительный переход в центре битового интервала (то есть первая половина битового интервала – низкий уровень, вторая половина – высокий), а логической единице соответствует отрицательный переход в центре битового интервала (или наоборот).
Как и в RZ, обязательное наличие перехода в центре бита позволяет приемнику манчестерского кода легко выделить из пришедшего сигнала синхросигнал и передать информацию сколь угодно большими последовательностями без потерь из-за рассинхронизации. Допустимое расхождение часов приемника и передатчика может достигать 25%.
Подобно коду RZ, при использовании манчестерского кода требуется пропускная способность линии в два раза выше, чем при применении простейшего кода NRZ. Например, для скорости передачи 10 Мбит/с требуется полоса пропускания 10 МГц (рис. 3.15).
Скорость передачи и пропускная способность при манчестерском коде
Рис. 3.15. Скорость передачи и пропускная способность при манчестерском коде
Как и при коде RZ, в данном случае приемник легко может определить не только начало передаваемой последовательности бит, но и ее конец. Если в течение битового интервала нет перехода сигнала, то прием заканчивается. В манчестерском коде можно передавать последовательности бит переменной длины (рис. 3.16). Процесс определения времени передачи называют еще контролем несущей, хотя в явном виде несущей частоты в данном случае не присутствует.
Определение начала и конца приема при манчестерском коде
Рис. 3.16. Определение начала и конца приема при манчестерском коде
Манчестерский код используется как в электрических, так и в оптоволоконных кабелях (в последнем случае один уровень соответствует отсутствию света, а другой – его наличию).
Основное достоинство манчестерского кода – постоянная составляющая в сигнале (половину времени сигнал имеет высокий уровень, другую половину – низкий). Постоянная составляющая равна среднему значению между двумя уровнями сигнала.
Если высокий уровень имеет положительную величину, а низкий – такую же отрицательную, то постоянная составляющая равна нулю. Это дает возможность легко применять для гальванической развязки импульсные трансформаторы. При этом не требуется дополнительного источника питания для линии связи (как, например, в случае использования оптронной гальванической развязки), резко уменьшается влияние низкочастотных помех, которые не проходят через трансформатор, легко решается проблема согласования.
Если же один из уровней сигнала в манчестерском коде нулевой (как, например, в сети Ethernet), то величина постоянной составляющей в течение передачи будет равна примерно половине амплитуды сигнала. Это позволяет легко фиксировать столкновения пакетов в сети (конфликт, коллизию) по отклонению величины постоянной составляющей за установленные пределы.
Частотный спектр сигнала при манчестерском кодировании включает в себя только две частоты: при скорости передачи 10 Мбит/с это 10 МГц (соответствует передаваемой цепочке из одних нулей или из одних единиц) и 5 МГц (соответствует последовательности из чередующихся нулей и единиц: 1010101010...). Поэтому с помощью простейших полосовых фильтров можно легко избавиться от всех других частот (помехи, наводки, шумы).
Бифазный код
Бифазный код часто рассматривают как разновидность манчестерского, так как их характеристики практически полностью совпадают.
Данный код отличается от классического манчестерского кода тем, что он не зависит от перемены мест двух проводов кабеля. Особенно это удобно в случае, когда для связи применяется витая пара, провода которой легко перепутать. Именно этот код используется в одной из самых известных сетей Token-Ring компании IBM.
Принцип данного кода прост: в начале каждого битового интервала сигнал меняет уровень на противоположный предыдущему, а в середине единичных (и только единичных) битовых интервалов уровень изменяется еще раз. Таким образом, в начале битового интервала всегда есть переход, который используется для самосинхронизации. Как и в случае классического манчестерского кода, в частотном спектре при этом присутствует две частоты. При скорости 10 Мбит/с это частоты 10 МГц (при последовательности одних единиц: 11111111...) и 5 МГц (при последовательности одних нулей: 00000000...).
Имеется также еще один вариант бифазного кода (его еще называют дифференциальным манчестерским кодом). В этом коде единице соответствует наличие перехода в начале битового интервала, а нулю – отсутствие перехода в начале битового интервала (или наоборот). При этом в середине битового интервала переход имеется всегда, и именно он служит для побитовой самосинхронизации приемника. Характеристики этого варианта кода также полностью соответствуют характеристикам манчестерского кода.
Здесь же стоит упомянуть о том, что часто совершенно неправомерно считается, что единица измерения скорости передачи бод – это то же самое, что бит в секунду, а скорость передачи в бодах равняется скорости передачи в битах в секунду. Это верно только в случае кода NRZ. Скорость в бодах характеризует не количество передаваемых бит в секунду, а число изменений уровня сигнала в секунду. И при RZ или манчестерском кодах требуемая скорость в бодах оказывается вдвое выше, чем при NRZ. В бодах измеряется скорость передачи сигнала, а в битах в секунду – скорость передачи информации. Поэтому, чтобы избежать неоднозначного понимания, скорость передачи по сети лучше указывать в битах в секунду (бит/с, Кбит/с, Мбит/с, Гбит/с).
Другие коды
Все разрабатываемые в последнее время коды призваны найти компромисс между требуемой при заданной скорости передачи полосой пропускания кабеля и возможностью самосинхронизации. Разработчики стремятся сохранить самосинхронизацию, но не ценой двукратного увеличения полосы пропускания, как в рассмотренных RZ, манчестерском и бифазном кодах.
Чаще всего для этого в поток передаваемых битов добавляют биты синхронизации. Например, один бит синхронизации на 4, 5 или 6 информационных битов или два бита синхронизации на 8 информационных битов. В действительности все обстоит несколько сложнее: кодирование не сводится к простой вставке в передаваемые данные дополнительных битов. Группы информационных битов преобразуются в передаваемые по сети группы с количеством битов на один или два больше. Приемник осуществляет обратное преобразование, восстанавливает исходные информационные биты. Довольно просто осуществляется в этом случае и обнаружение несущей частоты (детектирование передачи).
Так, например, в сети FDDI (скорость передачи 100 Мбит/с) применяется код 4В/5В, который 4 информационных бита преобразует в 5 передаваемых битов. При этом синхронизация приемника осуществляется один раз на 4 бита, а не в каждом бите, как в случае манчестерского кода. Но зато требуемая полоса пропускания увеличивается по сравнению с кодом NRZ не в два раза, а только в 1,25 раза (то есть составляет не 100 МГц, а всего лишь 62,5 МГц). По тому же принципу строятся и другие коды, в частности, 5В/6В, используемый в стандартной сети 100VG-AnyLAN, или 8В/10В, применяемый в сети Gigabit Ethernet.
В сегменте 100BASE-T4 сети Fast Ethernet использован несколько иной подход. Там применяется код 8В/6Т, предусматривающий параллельную передачу трех трехуровневых сигналов по трем витым парам. Это позволяет достичь скорости передачи 100 Мбит/с на дешевых кабелях с витыми парами категории 3, имеющих полосу пропускания всего лишь16 МГц (см. табл. 2.1). Правда, это требует большего расхода кабеля и увеличения количества приемников и передатчиков. К тому же принципиально, чтобы все провода были одной длины и задержки сигнала в них не слишком различались.
Иногда уже закодированная информация подвергается дополнительному кодированию, что позволяет упростить синхронизацию на приемном конце. Наибольшее распространение для этого получили 2-уровневый код NRZI, применяемый в оптоволоконных сетях (FDDI и 100BASE-FX), а также 3-уровневый код MLT-3, используемый в сетях на витых парах (TPDDI и 100BASE-TХ). Оба эти кода (рис. 3.17) не являются самосинхронизирующимися.
Коды NRZI и MLT-3
Рис. 3.17. Коды NRZI и MLT-3
Код NRZI (без возврата к нулю с инверсией единиц – Non-Return to Zero, Invert to one) предполагает, что уровень сигнала меняется на противоположный в начале единичного битового интервала и не меняется при передаче нулевого битового интервала. При последовательности единиц на границах битовых интервалов имеются переходы, при последовательности нулей – переходов нет. В этом смысле код NRZI лучше синхронизируется, чем NRZ (там нет переходов ни при последовательности нулей, ни при последовательности единиц).
Код MLT-3 (Multi-Level Transition-3) предполагает, что при передаче нулевого битового интервала уровень сигнала не меняется, а при передаче единицы – меняется на следующий уровень по такой цепочке: +U, 0, –U, 0, +U, 0, –U и т.д. Таким образом, максимальная частота смены уровней получается вчетверо меньше скорости передачи в битах (при последовательности сплошных единиц). Требуемая полоса пропускания оказывается меньше, чем при коде NRZ.
Все упомянутые в данном разделе коды предусматривают непосредственную передачу в сеть цифровых двух- или трехуровневых прямоугольных импульсов.
Однако иногда в сетях используется и другой путь – модуляция информационными импульсами высокочастотного аналогового сигнала (синусоидального). Такое аналоговое кодирование позволяет при переходе на широкополосную передачу существенно увеличить пропускную способность канала связи (в этом случае по сети можно передавать несколько бит одновременно). К тому же, как уже отмечалось, при прохождении по каналу связи аналогового сигнала (синусоидального) не искажается форма сигнала, а только уменьшается его амплитуда, а в случае цифрового сигнала форма сигнала искажается (см. рис. 3.2).
К самым простым видам аналогового кодирования относятся следующие (рис. 3.18):
* Амплитудная модуляция (АМ, AM – Amplitude Modulation), при которой логической единице соответствует наличие сигнала (или сигнал большей амплитуды), а логическому нулю – отсутствие сигнала (или сигнал меньшей амплитуды). Частота сигнала при этом остается постоянной. Недостаток амплитудной модуляции состоит в том, что АМ-сигнал сильно подвержен действию помех и шумов, а также предъявляет повышенные требования к затуханию сигнала в канале связи. Достоинства – простота аппаратурной реализации и узкий частотный спектр.
Аналоговое кодирование цифровой информации
Рис. 3.18. Аналоговое кодирование цифровой информации
* Частотная модуляция (ЧМ, FM – Frequency Modulation), при которой логической единице соответствует сигнал более высокой частоты, а логическому нулю – сигнал более низкой частоты (или наоборот). Амплитуда сигнала при частотной модуляции остается постоянной, что является большим преимуществом по сравнению с амплитудной модуляцией.
* Фазовая модуляция (ФМ, PM – Phase Modulation), при которой смене логического нуля на логическую единицу и наоборот соответствует резкое изменение фазы синусоидального сигнала одной частоты и амплитуды. Важно, что амплитуда модулированного сигнала остается постоянной, как и в случае частотной модуляции.
Применяются и значительно более сложные методы модуляции, являющиеся комбинацией перечисленных простейших методов. Чаще всего аналоговое кодирование используется при передаче информации по каналу с узкой полосой пропускания, например, по телефонным линиям в глобальных сетях. Кроме того, аналоговое кодирование применяется в радиоканалах, что позволяет обеспечивать связь между многими пользователями одновременно. В локальных кабельных сетях аналоговое кодирование практически не используется из-за высокой сложности и стоимости как кодирующего, так и декодирующего оборудования.
В этой статье описываются полезные функции и процедуры, помогающие эффективно работать с различными типами данных в системе "1С:Предприятие 7.7".
Форматирование данных в 1С
Список значений в 1С
Таблица значений в 1С
Таблица или печатная форма в 1С
Периоды и даты в 1С
Календари и праздники в 1С
[pagebreak]
Справочники в 1С
Документы в 1С
Предопределённые функции и процедуры в 1С
Налоговый учёт и первое событие в 1С
Резюме
В статье описаны функции и процедуры, используемые в программе "1С:Предприятие 7.7" для работы со справочниками, документами, списками значений, таблицами значений и с прочими агрегатными типами данных. Образцы практического применения описанных средств Вы сможете найти в статьях "Отчёты для 1С" и "Обработки для 1С".
В этой статье будет рассмотрен скрипт, который создает анимацию в виде падающего снега. Анимация воспроизводится в заданной области web-страницы. Анимационный эффект, создаваемый данным скриптом выглядит весьма привлекательно, поэтому скрипт вполне может быть использован для создания анимированных логотипов, или блоков новогодних объявлений и поздравлений на сайте.
Область web-страницы, в которой производится анимация, задается элементом DIV с идентификатором ID_ANIMATE. Принцип работы скрипта заключается в вертикальном перемещении (с небольшими стохастическими перемещениями по горизонтали) элементов IMG, представляющих изображение снежинки в пределах этого элемента (элемент DIV с идентификатором ID_ANIMATE является элементом-контейнером для элементов IMG).
Элемент-контейнер DIV с идентификатором ID_ANIMATE определяется при помощи HTML-разметки в документе, в котором содержится скрипт. В этот элемент может быть помещено произвольное гипертекстовое содержимое, которое будет располагаться "на фоне" падающих снежинок, либо на фоне которого будут падать снежинки (это зависит от значения позиционного уровня этого содержимого). Код фрагмента HTML-разметки, определяющей элемент-контейнер DIV и его содержимое в демо-примере, приложенном к статье (см. демо-пример), приведен далее:
Параметры элемента-контейнера DIV (его размеры, схема позиционирования, значение свойства переполнения, цвет фона, параметры границы), а также перемещаемых в нем элементов IMG (схема позиционирования, размер, значение позиционного уровня), определяются правилами внедренной в документ таблицы слилей CSS:
Как можно видеть из листинга, элементам IMG, являющимся потомками элемента DIV с идентификатором ID_ANIMATE, назначается значение позиционного уровня 1. Поэтому, если вы хотите, чтобы "снежинки" двигались "под" остальным содержимым этого элемента, содержимому следует задать значение позиционного уровня больше 1 (как это сделано в демо-примере). Обратите также внимание на то, что элементам IMG назначена схема абсолютного позиционирования.
Теперь рассмотрим непосредственно работу скрипта. Полный листинг кода скрипта приведен далее.
Как можно видеть из листинга, в начале скрипта производится инициализация нескольких переменных. В переменную oAnimate заносится ссылка на DOM-объект элемента DIV с идентификатором ID_ANIMATE. Переменные nWidth и nHeight инициализируются значениями значения ширины и высоты этого элемента. Переменная nFSize должна содержать значение высоты (в пикселях) элементов изображений-снежинок (оно должно быть таким же, как задано в таблице стилей). Переменная strFlakeURL содержит URI ресурса изображения снежинки. Значение переменной nCount определяет общее количество движущихся изображений. Массив aoFlakes предназначен для хранения ссылок на DOM-объекты элементов изображений-снежинок.
Создание элементов изображений, добавление их в дерево документа, ссылок на DOM-объекты этих элементов в массив aoFlakes производится в процессе инициализации скрипта (см. окончание листинга кода скрипта). Значению свойства src DOM-объектов элементов изображений при этом присваивается значение переменной strFlakeURL. Для установки параметров движения каждого созданного элемента, вызывается функция ResetFlake. Для позиционирования соответствующего элемента IMG относительно элемента-контейнера DIV - UpdateFlakePos.
Функция ResetFlake устанавливает значения свойствам m_nX, m_nY и m_nSpeed DOM-объекта элемента, ссылка на который содержится в элементе массива aoFlakes с индексом, равным значению первого параметра ResetFlake. Свойство m_nX объекта хранит текущую координату по оси X, а свойство m_nY - по оси Y соответствующего элемента относительно контейнера. Свойство m_nSpeed определяет "скорость" движения элемента (величину его вертикального смещения на каждом шаге анимации). Функция ResetFlake устанавливает случайные значения свойствам m_nX и m_nSpeed. Свойству m_nY случайное значение устанавливается только в том случае, если параметр bRandY функции вычисляется в true (в этом случае элемент изображения снежинки будет иметь случайную позицию по вертикали). Иначе свойству m_nY устанавливаетя значение -nFSize (при этом изображение будет позиционироваться так, что оно будет полностью скрыто за верхней границей элемента-контейнера). При создании элементов изображений в процессе инициализации скрипта, ResetFlake вызывается со значением параметра bRandY, равным true.
Функция UpdateFlakePos принимает в качестве единственного параметра значение индекса в массиве aoFlakes и производит позиционирование элемента, ссылка на DOM-объект которого содержится в элементе массива aoFlakes с данным индексом в соответствии со значениями его свойств m_nX и m_nY.
Перемещение всех изображений-снежинок осуществляется функцией OnTimer, которая является обработчиком событий таймера, запускаемого в процессе инициализации скрипта.
Как можно видеть из приведенного ранее листинга кода скрипта, в функции OnTimer производится перебор всех DOM-объектов элементов изображений снежинок. Значение свойства m_nY каждого из этих объектов наращивается на величину его свойства m_nSpeed. Значение свойства m_nX изменяется на случайную величину, которая находится в диапазоне [-1..1] (так достигается случайное горизонтальное движение "снежинок"). В случае, если элемент изображения вышел за нижнюю границу элемента-контейнера, вызывается функция ResetFlake, которая устанавливает случайные значения свойств m_nX и m_nSpeed соответствующего объекта, а значение его свойства m_nY устанавливаетт в -nFSize. Затем вызывается функция UpdateFlakePos для перемещения конкретного элемента IMG в нужную позицию.
Выбор ключевых слов является одним из важнейших этапов оптимизации сайта под поисковые системы. Так как поисковики являются основным источником целевых посетителей, то этому вопросу надо уделять особое внимание. Правильно подобранные ключевые слова помогут пользователям легко находить страницы сайта, а также повысят их позицию в результатах выдачи по запросу.
Итак, для начала необходимо проанализировать тематику сайта и постараться взглянуть на него глазами посетителя. Цель такого упражнения-разминки – подбор слов и выражений, по которым, на ваш взгляд, производится поиск подобных сайтов.
Теперь можно приступить к детализации задачи, а именно, подбору ключевых слов для каждой страницы сайта отдельно. Большинство начинающих разработчиков при оптимизации допускают одну критическую ошибку, а именно, оптимизируют все страницы под одни и те же запросы. Они не учитывают тот факт, что машины поиска каждую страницу рассматривают независимо от остальных, поэтому необходимо оптимизировать страницы по отдельности, тщательно подбирая для них ключевые слова.
При анализе страницы необходимо написать около двух десятков ключевых слов, из которых попробовать сформировать фразы с учетом возможностей морфологического поиска и расположить слова и выражения в порядке их соответствия тематике страницы.
Например, ваша компания занимается продажей бытовой техники. Вместо использования в тегах HTML-кода и содержимом страниц ключевой фразы “продажа бытовой техники”, нужно уточнить эту фразу в зависимости от содержимого каждой страницы. Если на данной странице внимание сфокусировано, например, на кухонных комбайнах, то теги и текст необходимо оптимизировать именно под это выражение.
Сейчас идет тенденция к оптимизации страниц больше под ключевые выражения, чем под отдельные слова. Это связано с повышением уровня интернет-пользователей, которые для уточнения поисковых запросов из ключевых слов с помощью служебных символов строят ключевые фразы, значительно повышающие релевантность результатов поиска.
Следующий этап - это анализ частоты запросов по пунктам списка, составленного на этапе обдумывания тематики сайта. Здесь уже придется излагать не свое видение сайта, а вооружиться поисковой системой. Желательно брать тот поисковик, в трафике которого вы больше всего заинтересованы.
Составленный список предполагаемых ключевых слов можно проверить, например, с помощью сервиса «Яндекс.Директ» и выделить в нем фразы, сходные с заданными изначально. Далее необходимо посмотреть количество запросов для каждого выражения, выбранного на первом этапе, и попробовать найти фразы-синонимы. Если для них количество запросов будет больше, есть смысл заменить первоначальный вариант.
Чтобы выявить близкие по значению выражения, можно использовать сервис «Рамблер-Ассоциации», который представляет статистику поисковых запросов и работает по принципу «Те, кто ищут [запрос пользователя], ищут также». Сервис предназначен в помощь пользователю, совершившему поиск по какому-либо запросу и не получившему нужной информации. Статистика “ассоциаций” помогает выяснить интересы пользователей, путем анализа списка запросов, схожих с основным. Для выявления англоязычных запросов можно использовать сервис Wordtracker, который в бесплатной версии выдает ограниченные отчеты по поисковым запросам.
Теперь необходимо проанализировать полученную статистику запросов по списку ключевых слов. Если по некоторым из них результаты зашкаливают за десятки тысяч, их однозначно можно убрать из дальнейшего рассмотрения т.к. эти слова используются многими конкурентами. Здесь надо учесть тот факт, что если для оптимизации будет выбрана слишком распространенная ключевая фраза, то потребуется много времени и сил, чтобы взобраться на вершину ранжированного списка результатов. Кроме того, привлеченный таким образом сетевой трафик будет плохо сфокусирован, т.е. процент целевых покупателей будет невелик. С другой стороны, если для ключевой фразы будет получено малое число результатов, то эффективность такой оптимизации также буде невысока.
Чтобы добиться компромисса в этом сложном вопросе, надо брать ключевую фразу, которая является оптимальной для тематики страницы и высоко конкурентной, и добавлять в нее описательные слова или, например, конкретные модели и торговые марки, т.е. конкретизировать представленную на странице информацию.
Часто многие сайты для привлечения большего числа посетителей используют для ключевых слов практически на всех страницах выражения типа “все модели”, “весь модельный ряд”, “огромный выбор” и т.д. Если на вашем сайте в самом деле представлены все модели некоторой торговой марки или же подавляющее большинство их, то лучшим вариантом будет оптимизация под такой запрос какой-то одной страницы, например с самой популярной моделью. При этом на этой странице обязательно должны быть ссылки на другие модели или на страницу с кратким представлением всех моделей в удобном для сравнения виде. Если в ключевой фразе перечисляются конкретные модели, то необходимо располагать их в порядке убывания популярности.
Очень часто при вводе поискового запроса пользователи не пишут прописные буквы в названиях компаний, торговых марок, городов и т.п. Т.к. некоторые системы поиска чувствительны к регистру символов, т.е. поиск по вариантам фразы с символами, преобразованными в нижний регистр, и с символами в верхнем регистре приводит к разным результатам. Поэтому, чтобы улучшить результаты поиска своего сайта, надо добавлять на страницы все варианты написания ключевой фразы. Если во фразе используются слова, которые по правилам языка пишутся с прописной буквы, то можно использовать ее версию со строчными буквами там, где она не будет видна для посетителей.
В зависимости от того, под какую систему поиска оптимизируется сайт, необходимо узнать поддерживается ли ей морфологический поиск, т.е. поиск по слову во всех его морфологических формах. Это значит, что поиск по фразе «оптовая покупка скидка» может быть интерпретирован, как “при оптовой покупке скидки” и т.д. Чтобы определить, выполняет ли данный поисковик морфологическую функцию, можно проработать поиск по различным версиям ключевой фразы и проанализировать результаты.
Необходимо не только постоянно проводить мониторинг частоты использования вашей ключевой фразы пользователями, но и отслеживать, как много других страниц также оптимизированы под нее. Т.е. надо постоянно следить за конкурирующими ресурсами, которые стоят первыми в рейтинге при запросе по данной тематике.
Таким образом, выбор наиболее эффективных ключевых фраз может буквально поставить на ноги ваш онлайновый бизнес, а неудачный, наоборот, разрушить его. Главное не забывать, что каждая страница оптимизируется под одну-две ключевые фразы, которые четко соответствуют ее тематике.
Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.
Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).
Как работают расширенные хранимые процедуры.
* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.
Особенности расширенных хранимых процедур.
* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр
Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.
Создание расширенных хранимых процедур.
Расширенная хранимая процедура эта функция имеющая следующий прототип:
Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:
* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.
Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:
Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.
Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:
- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0
Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.
Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.
На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.
Постановка задачи.
Прежде чем приступать к программированию, необходимо чётко представлять с чего начать, какой должен быть конечный результат, и каким способом его добиться. Итак, вот нам техническое задание:
Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.
.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:
Работа с входными параметрами
В этой главе я не хочу рассеивать Ваше внимание на посторонних вещах, а хочу сосредоточить его на работе с переданными в расширенную хранимую процедуру параметрами. Поэтуму мы несколько упростим наше техническое задание и разработаем тольку ту его часть, которая работает с входными параметрами. Но сначал не много теории
Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:
- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .
Теперь рассмотрим подробно каждый пункт:
Определение количества переданных в расширенную хранимую процедуру параметров
Для получения количества переданных параметров необходимо использовать функцию:
.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .
[pagebreak]
Определение типа данных и длины переданых параметров
Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:
.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.
Проверка, является ли второй параметр OUTPUT параметром.
Функция srv_paramstatus() предназначена для определения статуса переданного параметра:
.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.
Установка значения выходного параметра.
Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.
.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.
. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:
msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
В процессе работы расширенная хранимая процедура должна регулярно сообщать клиентскому приложению свой статус, т.е. посылать сообщения о выполненных действиях. Для этого и предназначена функция srv_senddone:
status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
Установка расширенных хранимых процедур на MS SQL Server 2000
1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:
Заключение
На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!
Как известно, поисковая система проиндексирует ваш сайт, если вы сами добавите свой ресурс в базу данных или если на ваш сайт будет стоять ссылка с другого сайта. Кроме всего прочего, в Яндексе количество таких ссылок влияет на Индекс Цитирования вашего сайта. Давайте посмотрим, какие еще особенности этой поисковой системы нам стоит учесть.
Робот-паук у Яндекса называется yandex (регистр значения не имеет). Так к нему можно обращаться через файл robots.txt.
Не стоит спешить добавлять незаконченные сайты, чтобы только их поскорее проиндексировать. Робот настраивает свой график посещений таким образом, что на вашу страницу за обновленным контентом может придти не скоро.
Переиндексация документа происходит примерно раз в две недели, но под каждый сайт робот подстраивается в отдельности. Все зависит от частоты обновления. По словам Яндекса, тег никакой роли в работе робота не играет.
Робот yandex индексирует все документы в русскоязычной части Интернета (в том числе и страны СНГ). Впрочем, мой сайт Яндекс принял без проблем через сервис AddURL и проиндексировал в течение недели. Главный критерий приема - текст должен быть написан на русском. Кстати, воспользовавшись этим же сервисом, вы сможете увидеть какие страницы вашего сайта занесены в Яндекс и проиндексирован ли он вообще.
Информация в заголовке (тег title) Яндекс отображает в результатах поиска, так что постарайтесь сделать содержательный заголовок, вкратце описать данную страницу. Слова, находящиеся в теге title, имеют больший вес чем все остальные. Постарайтесь включить в заголовок ключевое слово этой страницы, так у вас появиться шанс быть выше в списке при поиске по данному слову.
Не стоит в тег запихивать все самые популярные ключевые слова. Такой подход вряд ли прибавит вес документу. Самый оптимальный вариант - комплектовать на каждой странице свой набор ключевых слов, которые наиболее характерны для описываемого текста. Ключевые слова в теге также увеличивают вес слова в документе, но только если само слово находится на странице.
Помимо вышеперечисленных способов, на релевантность слова влияют частота его использования в заголовках (h1, h2 ...), в атрибуте alt, во всплывающих подсказках и процент встречаемости этого слова в документе, т.е. как часто вы его используете. Но при этом сохраните смысл документа, иначе Яндекс может посчитать ваше слово спамом.
Индекс цитирования
В каталоге Яндекса используется такое понятие, как тематический индекс цитирования (тИЦ). Он определяется количеством и качеством внешних ссылок на ваш сайт. С количеством ссылок все понятно, а как насчет качества? На качество ссылки влияет тИЦ ресурса, ссылающегося на вас. Немаловажную роль играет тематическая близость вашего сайта с ссылающимися на вас ресурсами.
При подсчете вашего индекса цитирования не берутся во внимание ссылки с форумов, веб-досок, конференций, с сайтов, расположенных на бесплатных хостингах (если они не описаны в каталоге Яндекса). Естественно, не учитываются ссылки с тех сайтов, которые Яндекс не индексирует (например, зарубежные сайты).
"А зачем вообще нужен этот индекс цитирования?" - спросите вы. тИЦ сайта такая же мера измерения, как и хосты, Разница только в одном: количество хостов зависит от посетителей (чем их больше, тем больше хостов), а индекс цитирования Яндекса - от авторов сайтов (чем больше авторов поставят ссылку на ваш ресурс, тем выше значение CY).
По значению индекса цитирования определяется релевантность ресурса в каталоге Яндекса и, соответственно, позиция вашего сайта в выбранном разделе.
Сетевой уровень в первую очередь должен предоставлять средства для решения следующих задач:
* доставки пакетов в сети с произвольной топологией,
* структуризации сети путем надежной локализации трафика,
* согласования различных протоколов канального уровня.
Локализация трафика и изоляция сетей
Трафик в сети складывается случайным образом, однако в нем отражены и некоторые закономерности. Как правило, некоторые пользователи, работающие над общей задачей, (например, сотрудники одного отдела) чаще всего обращаются с запросами либо друг к другу, либо к общему серверу, и только иногда они испытывают необходимость доступа к ресурсам компьютеров другого отдела.
Желательно, чтобы структура сети соответствовала структуре информационных потоков. В зависимости от сетевого трафика компьютеры в сети могут быть разделены на группы (сегменты сети). Компьютеры объединяются в группу, если большая часть порождаемых ими сообщений, адресована компьютерам этой же группы.
Для разделения сети на сегменты используются мосты и коммутаторы. Они экранируют локальный трафик внутри сегмента, не передавая за его пределы никаких кадров, кроме тех, которые адресованы компьютерам, находящимся в других сегментах. Тем самым, сеть распадается на отдельные подсети. Это позволяет более рационально выбирать пропускную способность имеющихся линий связи, учитывая интенсивность трафика внутри каждой группы, а также активность обмена данными между группами.
Однако локализация трафика средствами мостов и коммутаторов имеет существенные ограничения.
С одной стороны, логические сегменты сети, расположенные между мостами, недостаточно изолированы друг от друга, а именно, они не защищены от, так называемых, широковещательных штормов. Если какая-либо станция посылает широковещательное сообщение, то это сообщение передается всем станциям всех логических сегментов сети. Защита от широковещательных штормов в сетях, построенных на основе мостов, имеет количественный, а не качественный характер: администратор просто ограничивает количество широковещательных пакетов, которое разрешается генерировать некоторому узлу.
С другой стороны, использование механизма виртуальных сегментов, реализованного в коммутаторах локальных сетей, приводит к полной локализации трафика - такие сегменты полностью изолированы друг от друга, даже в отношении широковещательных кадров. Поэтому в сетях, построенных только на мостах и коммутаторах, компьютеры, принадлежащие разным виртуальным сегментам, не образуют единой сети.
Приведенные недостатки мостов и коммутаторов связаны с тем, что они работают по протоколам канального уровня, в которых в явном виде не определяется понятие части сети (или подсети, или сегмента), которое можно было бы использовать при структуризации большой сети. Вместо того, чтобы усовершенствовать канальный уровень, разработчики сетевых технологий решили поручить задачу построения составной сети новому уровню - сетевому.
Согласование протоколов канального уровня
Современные вычислительные сети часто строятся с использованием нескольких различных базовых технологий - Ethernet, Token Ring или FDDI. Такая неоднородность возникает либо при объединении уже существовавших ранее сетей, использующих в своих транспортных подсистемах различные протоколы канального уровня, либо при переходе к новым технологиям, таким, как Fast Ethernet или 100VG-AnyLAN.
Именно для образования единой транспортной системы, объединяющей несколько сетей с различными принципами передачи информации между конечными узлами, и служит сетевой уровень. Когда две или более сетей организуют совместную транспортную службу, то такой режим взаимодействия обычно называют межсетевым взаимодействием (internetworking). Для обозначения составной сети в англоязычной литературе часто также используется термин интерсеть (internetwork или internet).
Создание сложной структурированной сети, интегрирующей различные базовые технологии, может осуществляться и средствами канального уровня: для этого могут быть использованы некоторые типы мостов и коммутаторов. Однако возможностью трансляции протоколов канального уровня обладают далеко не все типы мостов и коммутаторов, к тому же возможности эти ограничены. В частности, в объединяемых сетях должны совпадать максимальные размеры полей данных в кадрах, так как канальные протоколы, как правило, не поддерживают функции фрагментации пакетов.
Маршрутизация в сетях с произвольной топологией
Среди протоколов канального уровня некоторые обеспечивают доставку данных в сетях с произвольной топологией, но только между парой соседних узлов (например, протокол PPP), а некоторые - между любыми узлами (например, Ethernet), но при этом сеть должна иметь топологию определенного и весьма простого типа, например, древовидную.
При объединении в сеть нескольких сегментов с помощью мотов или коммутаторов продолжают действовать ограничения на ее топологию: в получившейся сети должны отсутствовать петли. Действительно, мост или его функциональный аналог - коммутатор - могут решать задачу доставки пакета адресату только тогда, когда между отправителем и получателем существует единственный путь. В то же время наличие избыточных связей, которые и образуют петли, часто необходимо для лучшей балансировки нагрузки, а также для повышения надежности сети за счет существования альтернативного маршрута в дополнение к основному.
Сетевой уровень позволяет передавать данные между любыми, произвольно связанными узлами сети.
Реализация протокола сетевого уровня подразумевает наличие в сети специального устройства - маршрутизатора. Маршрутизаторы объединяют отдельные сети в общую составную сеть. Внутренняя структура каждой сети не показана, так как она не имеет значения при рассмотрении сетевого протокола. К каждому маршрутизатору могут быть присоединены несколько сетей (по крайней мере две).
В сложных составных сетях почти всегда существует несколько альтернативных маршрутов для передачи пакетов между двумя конечными узлами. Задачу выбора маршрутов из нескольких возможных решают маршрутизаторы, а также конечные узлы.
Маршрут - это последовательность маршрутизаторов, которые должен пройти пакет от отправителя до пункта назначения.
Маршрутизатор выбирает маршрут на основании своего представления о текущей конфигурации сети и соответствующего критерия выбора маршрута. Обычно в качестве критерия выступает время прохождения маршрута, которое в локальных сетях совпадает с длиной маршрута, измеряемой в количестве пройденных узлов маршрутизации (в глобальных сетях принимается в расчет и время передачи пакета по каждой линии связи).
[pagebreak]
Сетевой уровень и модель OSI
В модели OSI, называемой также моделью взаимодействия открытых систем (Open Systems Interconnection - OSI) и разработанной Международной Организацией по Стандартам (International Organization for Standardization - ISO), средства сетевого взаимодействия делятся на семь уровней, для которых определены стандартные названия и функции.
Сетевой уровень занимает в модели OSI промежуточное положение: к его услугам обращаются протоколы прикладного уровня, сеансового уровня и уровня представления. Для выполнения своих функций сетевой уровень вызывает функции канального уровня, который в свою очередь обращается к средствам физического уровня.
Рассмотрим коротко основные функции уровней модели OSI.
Физический уровень выполняет передачу битов по физическим каналам, таким, как коаксиальный кабель, витая пара или оптоволоконный кабель. На этом уровне определяются характеристики физических сред передачи данных и параметров электрических сигналов.
Канальный уровень обеспечивает передачу кадра данных между любыми узлами в сетях с типовой топологией либо между двумя соседними узлами в сетях с произвольной топологией. В протоколах канального уровня заложена определенная структура связей между компьютерами и способы их адресации. Адреса, используемые на канальном уровне в локальных сетях, часто называют МАС-адресами.
Сетевой уровень обеспечивает доставку данных между любыми двумя узлами в сети с произвольной топологией, при этом он не берет на себя никаких обязательств по надежности передачи данных.
Транспортный уровень обеспечивает передачу данных между любыми узлами сети с требуемым уровнем надежности. Для этого на транспортном уровне имеются средства установления соединения, нумерации, буферизации и упорядочивания пакетов.
Сеансовый уровень предоставляет средства управления диалогом, позволяющие фиксировать, какая из взаимодействующих сторон является активной в настоящий момент, а также предоставляет средства синхронизации в рамках процедуры обмена сообщениями.
Уровень представления. В отличии от нижележащих уровней, которые имеют дело с надежной и эффективной передачей битов от отправителя к получателю, уровень представления имеет дело с внешним представлением данных. На этом уровне могут выполняться различные виды преобразования данных, такие как компрессия и декомпрессия, шифровка и дешифровка данных.
Прикладной уровень - это в сущности набор разнообразных сетевых сервисов, предоставляемых конечным пользователям и приложениям. Примерами таких сервисов являются, например, электронная почта, передача файлов, подключение удаленных терминалов к компьютеру по сети.
При построении транспортной подсистемы наибольший интерес представляют функции физического, канального и сетевого уровней, тесно связанные с используемым в данной сети оборудованием: сетевыми адаптерами, концентраторами, мостами, коммутаторами, маршрутизаторами. Функции прикладного и сеансового уровней, а также уровня представления реализуются операционными системами и системными приложениями конечных узлов. Транспортный уровень выступает посредником между этими двумя группами протоколов.
Функции сетевого уровня
Протоколы канального уровня не позволяют строить сети с развитой структурой, например, сети, объединяющие несколько сетей предприятия в единую сеть, или высоконадежные сети, в которых существуют избыточные связи между узлами. Для того, чтобы, с одной стороны, сохранить простоту процедур передачи пакетов для типовых топологий, а с другой стороны, допустить использование произвольных топологий, вводится дополнительный сетевой уровень.
Прежде, чем приступить к рассмотрению функций сетевого уровня , уточним, что понимается под термином "сеть". В протоколах сетевого уровня термин "сеть" означает совокупность компьютеров, соединенных между собой в соответствии с одной из стандартных типовых топологий и использующих для передачи пакетов общую базовую сетевую технологию. Внутри сети сегменты не разделяются маршрутизаторами, иначе это была бы не одна сеть, а несколько сетей. Маршрутизатор соединят несколько сетей в интерсеть.
Основная идея введения сетевого уровня состоит в том, чтобы оставить технологии, используемые в объединяемых сетях в неизменном в виде, но добавить в кадры канального уровня дополнительную информацию - заголовок сетевого уровня, на основании которой можно было бы находить адресата в сети с любой базовой технологией. Заголовок пакета сетевого уровня имеет унифицированный формат, не зависящий от форматов кадров канального уровня тех сетей, которые могут входить в объединенную сеть.
Заголовок сетевого уровня должен содержать адрес назначения и другую информацию, необходимую для успешного перехода пакета из сети одного типа в сеть другого типа. К такой информации может относиться, например:
* номер фрагмента пакета, нужный для успешного проведения операций сборки-разборки фрагментов при соединении сетей с разными максимальными размерами кадров канального уровня,
* время жизни пакета, указывающее, как долго он путешествует по интерсети, это время может использоваться для уничтожения "заблудившихся" пакетов,
* информация о наличии и о состоянии связей между сетями, помогающая узлам сети и маршрутизаторам рационально выбирать межсетевые маршруты,
* информация о загруженности сетей, также помогающая согласовать темп посылки пакетов в сеть конечными узлами с реальными возможностями линий связи на пути следования пакетов,
* качество сервиса - критерий выбора маршрута при межсетевых передачах - например, узел-отправитель может потребовать передать пакет с максимальной надежностью, возможно в ущерб времени доставки.
В качестве адресов отправителя и получателя в составной сети используется не МАС-адрес, а пара чисел - номер сети и номер компьютера в данной сети. В канальных протоколах поле "номер сети" обычно отсутствует - предполагается, что все узлы принадлежат одной сети. Явная нумерация сетей позволяет протоколам сетевого уровня составлять точную карту межсетевых связей и выбирать рациональные маршруты при любой их топологии, используя альтернативные маршруты, если они имеются, что не умеют делать мосты.
Таким образом, внутри сети доставка сообщений регулируется канальным уровнем. А вот доставкой пакетов между сетями занимается сетевой уровень.
Существует два подхода к назначению номера узла в заголовке сетевого пакета. Первый основан на использовании для каждого узла нового адреса, отличного от того, который использовался на канальном уровне. Преимуществом такого подхода является его универсальность и гибкость - каков бы ни был формат адреса на канальном уровне, формат адреса узла на сетевом уровне выбирается единым. Однако, здесь имеются и некоторые неудобства, связанные с необходимостью заново нумеровать узлы, причем чаще всего вручную.
Второй подход состоит в использовании на сетевом уровне того же адреса узла, что был дан ему на канальном уровне. Это избавляет администратора от дополнительной работы по присвоению новых адресов, снимает необходимость в установлении соответствия между сетевым и канальным адресом одного и того же узла, но может породить сложную задачу интерпретации адреса узла при соединении сетей с разными форматами адресов.
Протоколы передачи данных и протоколы обмена маршрутной информацией
Для того, чтобы иметь информацию о текущей конфигурации сети, маршрутизаторы обмениваются маршрутной информацией между собой по специальному протоколу. Протоколы этого типа называются протоколами обмена маршрутной информацией (или протоколами маршрутизации). Протоколы обмена маршрутной информацией следует отличать от, собственно, протоколов сетевого уровня. В то время как первые несут чисто служебную информацию, вторые предназначены для передачи пользовательских данных, также, как это делают протоколы канального уровня.
Для того, чтобы доставить удаленному маршрутизатору пакет протокола обмена маршрутной информацией, используется протокол сетевого уровня, так как только он может передать информацию между маршрутизаторами, находящимися в разных сетях. Пакет протокола обмена маршрутной информацией помещается в поле данных пакета сетевого уровня, поэтому с точки зрения вложенности пакетов протоколы маршрутизации следует отнести к более высокому уровню, чем сетевой. Но функционально они решают общую задачу с пакетами сетевого уровня - доставляют кадры адресату через разнородную составную сеть.
С помощью протоколов обмена маршрутной информацией маршрутизаторы составляют карту межсетевых связей той или иной степени подробности и принимают решение о том, какому следующему маршрутизатору нужно передать пакет для образования рационального пути.
На сетевом уровне работают протоколы еще одного типа, которые отвечают за отображение адреса узла, используемого на сетевом уровне, в локальный адрес сети. Такие протоколы часто называют протоколами разрешения адресов - Address Resolution Protocol, ARP. Иногда их относят не к сетевому уровню, а к канальному, хотя тонкости классификации не изменяют их сути.
Каким способом можно производить поиск подходящих величин в момент ввода? Табличный курсор (визуально) должен перемещаться к наиболее подходящему значению при добавлении пользователем новых символов водимой величины.
Для поиска величины таблица держится открытой. Индекс должен, естественно, принадлежать полю, используемому элементом управления EditBox. В случае изменения содержимого EditBox, новое значение используется для вызова стандартной функции FindNearest таблицы TTable. Возвращаемая величина снова присваивается свойcтву Text элемента EditBox.
Я привел лишь общее решение задачи. Фактически во время изменения значения я включал таймер на период 1/3 секунды и в обработчике события OnTimer проводил операцию поиска (с выключением таймера). Это позволяло пользователю набирать без задержки нужный текст без необходимости производить поиск в расчете на вновь введенный символ (поиск проводился только при возникновении задержки в 1/3 секунды).
Вам также может понадобиться специальный обработчик нажатия клавиши backspace или добавления символа в любое место строки.
Вместо возвращения результатов элементу EditBox (который перезаписывает введенное пользователем значение), вы можете передавать результаты другому элементу управления, например компоненту ListBox. Вы также можете отобразить несколько наиболее подходящих значений, к примеру так:
Поиск
