Ну и жизнь настала, теперь 1С:Предприятие не только отлично считает финансы, но еще может проигрывать звуки и даже показывать видео там, где его показать практически невозможно - хоть на панели инструментов главного окна программы. Ну правда не без помощи WIN32API
Java нельзя понять, взглянув на него только как на коллекцию некоторых характеристик, - необходимо понять задачи этого языка как частные задачи программирования в целом.
Эта книга - о проблемах программирования: почему они стали проблемами, и какой подход использует Java в их решении. Поэтому обсуждаемые в каждой главе черты языка неразрывно связаны с тем, как они используются для решения определенных задач.
Эта книга, выдержавшая в оригинале не одно переиздание, за глубокое и поистине философское изложение тонкостей языка считается одним из лучших пособий для программирующих на Java.
В издании автор постарался полностью интегрировать усовершенствования Java SE5/6, включить и использовать их во всей книге.
Книга, которая у вас в руках, — это введение в язык программирования C+ + . Она начинается с азов: от читателя не требуется каких-либо знаний в области программирования. В отличие от других книг по программированию па C+ + , в этой книге вопрос "почему'' считается не менее важным, чем вопрос "как". И поэтому перед изложением конкретных особенностей языка C + + читателю разъясняется, как они действуют в целом. Ведь каждая структурная особенность языка - это отдельный штрих единой картины. Прочитав книгу, вы сможете написать на C + + вразумительную программу и, что не менее важно, будете понимать, почему и как она работает. Книга рассчитана на пользователей с различным уровнем подготовки.
PostgreSQL заслуженно считается одной из лучших СУБД, распространяемых с открытыми текстами, а по своим возможностям PostgreSQL успешно конкурирует со многими коммерческими пакетами.
Настоящая книга была задумана как практическое руководство по PostgreSQL версии 7.1.x, хотя большая часть материала в равной степени относится как к предыдущим, так и к будущим версиям PostgreSQL. При подборе материала авторы стремились к тому, чтобы читатель как можно быстрее освоил практические навыки работы с PostgreSQL. Хотя в книге затрагиваются некоторые теоретические аспекты функционирования СУБД, подобные теоретические отступления будут относительно короткими. Прежде всего, мы стремились к тому, чтобы полученные знания позволили читателю самостоятельно создать работоспособную базу данных PostgreSQL и обеспечить ее дальнейшее сопровождение. Надеемся, книга поможет всем, кто хочет ближе познакомиться с СУБД PostgreSQL и ее возможностями.
Книга ориентирована на широкий круг читателей, интересующихся объектно-реляционной системой управления базами данных (ОРСУБД) PostgreSQL. Предполагается, что читатель знаком с системами Linux и Unix, хотя и не является экспертом в области баз данных. Хотя все примеры тестировались в системе Red Hat Linux, практически весь материал относится к большинству систем семейства Unix.
В данной статье приведены общие сведения об организации работы системы 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С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.
Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.
Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.
В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.
В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.
Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".
Компоненты Delphi для работы с базами данных были созданы в расчете на работу с SQL и архитектурой клиент/сервер. При работе с ними вы можете воспользоваться характеристиками расширенной поддержки удаленных серверов. Delphi осуществляет эту поддержку двумя способами.
1. Введение
Во-первых, непосредственные команды из Delphi позволяют разработчику управлять таблицами, устанавливать пределы, удалять, вставлять и редактировать существующие записи.
Второй способ заключается в использовании запросов на языке SQL, где строка запроса передается на сервер для ее разбора, оптимизации, выполнения и передачи обратно результатов.
Данный документ делает акцент на втором методе доступа к базам данных, на основе запросов SQL (pass-through). Авторы не стремились создать курсы по изучению синтаксиса языка SQL и его применения, они ставили перед собой цель дать несколько примеров использования компонентов TQuery и TStoredProc. Но чтобы сделать это, необходимо понимать концепцию SQL и знать как работают selects, inserts, updates, views, joins и хранимые процедуры (stored procedures). Документ также вскользь касается вопросов управления транзакциями и соединения с базой данных, но не акцентирует на этом внимание. Итак, приступая к теме, создайте простой запрос типа SELECT и отобразите результаты.
2. Компонент TQuery
Если в ваших приложениях вы собираетесь использовать SQL, то вам непременно придется познакомиться с компонентом TQuery. Компоненты TQuery и TTable наследуются от TDataset. TDataset обеспечивает необходимую функциональность для получения доступа к базам данных. Как таковые, компоненты TQuery и TTable имеют много общих признаков. Для подготовки данных для показа в визуальных компонентах используется все тот же TDatasource. Также, для определения к какому серверу и базе данных необходимо получить доступ, необходимо задать имя псевдонима. Это должно выполняться установкой свойства aliasName объекта TQuery.
Свойство SQL
Все же TQuery имеет некоторую уникальную функциональность. Например, у TQuery имеется свойство с именем SQL. Свойство SQL используется для хранения SQL-запроса. Ниже приведены основные шаги для составления запроса, где все служащие имеют зарплату свыше $50,000.
Создайте объект TQuery
Задайте псевдоним свойству DatabaseName. (Данный пример использует псевдоним IBLOCAL, связанный с демонстрационной базой данных employee.gdb).
Выберите свойство SQL и щелкните на кнопке с текстом - '...' (три точки, Инспектор Объектов - В.О.). Должен появиться диалог редактора списка строк (String List Editor).
Введите:
. Нажмите OK.
Выберите в Инспекторе Объектов свойство Active и установите его в TRUE.
Разместите на форме объект TDatasource.
Установите свойство Dataset у TDatasource в Query1.
Разместите на форме TDBGrid.
Установите его свойство Datasource в Datasource1.
Свойство SQL имеет тип TStrings. Объект TStrings представляет собой список строк, и чем-то похож на массив. Тип данных TStrings имеет в своем арсенале команды добавления строк, их загрузки из текстового файла и обмена данными с другим объектом TStrings. Другой компонент, использующий TStrings - TMemo. В демонстрационном проекте ENTRSQL.DPR (по идее, он должен находится на отдельной дискетте, но к "Советам по Delphi" она не прилагается - В.О.), пользователь должен ввести SQL-запрос и нажать кнопку "Do It" ("сделать это"). Результаты запроса отображаются в табличной сетке. В Листинге 1 полностью приведен код обработчика кнопки "Do It".
Листинг 1
Свойство Params
Этого должно быть достаточно для пользователя, знающего SQL. Тем не менее, большинство пользователей не знает этого языка. Итак, ваша работа как разработчика заключается в предоставлении интерфейса и создании SQL-запроса. В Delphi, для создания SQL-запроса на лету можно использовать динамические запросы. Динамические запросы допускают использование параметров. Для определения параметра в запросе используется двоеточие (:), за которым следует имя параметра. Ниже приведе пример SQL-запроса с использованием динамического параметра:
Если вам нужно протестировать, или установить для параметра значение по умолчанию, выберите свойство Params объекта Query1. Щелкните на кнопке '...'. Должен появиться диалог настройки параметров. Выберите параметр Dept_no. Затем в выпадающем списке типов данных выберите Integer. Для того, чтобы задать значение по умолчанию, введите нужное значение в поле редактирования "Value".
Для изменения SQL-запроса во время выполнения приложения, параметры необходимо связать (bind). Параметры могут изменяться, запрос выполняться повторно, а данные обновляться. Для непосредственного редактирования значения параметра используется свойство Params или метод ParamByName. Свойство Params представляет из себя массив TParams. Поэтому для получения доступа к параметру, необходимо указать его индекс. Для примера,
Query1.params[0].asInteger := 900;
Свойство asInteger читает данные как тип Integer (название говорит само за себя). Это не обязательно должно указывать но то, что поле имеет тип Integer. Например, если тип поля VARCHAR(10), Delphi осуществит преобразование данных. Так, приведенный выше пример мог бы быть записан таким образом:
Query1.params[0].asString := '900';
или так:
Query1.params[0].asString := edit1.text;
Если вместо номера индекса вы хотели бы использовать имя параметра, то воспользуйтесь методом ParamByName. Данный метод возвращает объект TParam с заданным именем. Например:
Query1.ParamByName('DEPT_NO').asInteger := 900;
В листинге 2 приведен полный код примера.
Листинг 2
Обратите внимание на процедуру, первым делом подготовливающую запрос. При вызове метода prepare, Delphi посылает SQL запрос на удаленный сервер. Сервер выполняет грамматический разбор и оптимизацию запроса. Преимущество такой подготовки запроса состоит в его предварительном разборе и оптимизации. Альтернативой здесь может служить подготовка сервером запроса при каждом его выполнении. Как только запрос подготовлен, подставляются необходимые новые параметры, и запрос выполняется.
[pagebreak]
Источник данных
В предыдущем примере пользователь мог ввести номер отдела, и после выполнения запроса отображался список сотрудников этого отдела. А как насчет использования таблицы DEPARTMENT, позволяющей пользователю легко перемещаться между пользователями и отделами?
Примечание: Следующий пример использует TTable с именем Table1. Для Table1 имя базы данных IBLOCAL, имя таблицы - DEPARTMENT. DataSource2 TDatasource связан с Table1. Таблица также активна и отображает записи в TDBGrid.
Способ подключения TQuery к TTable - через TDatasource. Есть два основных способа сделать это. Во-первых, разместить код в обработчике события TDatasource OnDataChange. Например, листинг 3 демонстрирует эту технику.
Листинг 3 - Использования события OnDataChange для просмотра дочерних записей
Техника с использованием OnDataChange очень гибка, но есть еще легче способ подключения Query к таблице. Компонент TQuery имеет свойство Datasource. Определяя TDatasource для свойства Datasource, объект TQuery сравнивает имена параметров в SQL-запросе с именами полей в TDatasource. В случае общих имен, такие параметры заполняются автоматически. Это позволяет разработчику избежать написание кода, приведенного в листинге 3 (*** приведен выше ***).
Фактически, техника использования Datasource не требует никакого дополнительного кодирования. Для поключения запроса к таблице DEPT_NO выполните действия, приведенные в листинге 4.
Листинг 4 - Связывание TQuery c TTable через свойство Datasource
Выберите у Query1 свойство SQL и введите:
Выберите свойство Datasource и назначьте источник данных, связанный с Table1 (Datasource2 в нашем примере)
Выберите свойство Active и установите его в True
Это все, если вы хотите создать такой тип отношений. Тем не менее, существуют некоторые ограничения на параметризованные запросы. Параметры ограничены значениями. К примеру, вы не можете использовать параметр с именем Column или Table. Для создания запроса, динамически изменяемого имя таблицы, вы могли бы использовать технику конкатенации строки. Другая техника заключается в использовании команды Format.
Команда Format
Команда Format заменяет параметры форматирования (%s, %d, %n и пр.) передаваемыми значениями. Например,
Format('Select * from %s', ['EMPLOYEE'])
Результатом вышеприведенной команды будет 'Select * from EMPLOYEE'. Функция буквально делает замену параметров форматирования значениями массива. При использовании нескольких параметров форматирования, замена происходит слева направо. Например,
Результатом команды форматирования будет 'Select * from EMPLOYEE where EMP_ID=3'. Такая функциональность обеспечивает чрезвычайную гибкость при динамическом выполнении запроса. Пример, приведенный ниже в листинге 5, позволяет вывести в результатах поле salary. Для поля salary пользователь может задавать критерии.
Листинг 5 - Использование команды Format для создания SQL-запроса
В этом примере мы используем методы Clear и Add свойства SQL. Поскольку "подготовленный" запрос использует ресурсы сервера, и нет никакой гарантии что новый запрос будет использовать те же таблицы и столбцы, Delphi, при каждом изменении свойства SQL, осуществляет операцию, обратную "подготовке" (unprepare). Если TQuery не был подготовлен (т.е. свойство Prepared установлено в False), Delphi автоматически подготавливает его при каждом выполнении. Поэтому в нашем случае, даже если бы был вызван метод Prepare, приложению от этого не будет никакой пользы.
Open против ExecSQL
В предыдущих примерах TQuerie выполняли Select-запросы. Delphi рассматривает результаты Select-запроса как набор данных, типа таблицы. Это просто один класс допустимых SQL-запросов. К примеру, команда Update обновляет содержимое записи, но не возвращает записи или какого-либо значения. Если вы хотите использовать запрос, не возвращающий набор данных, используйте ExecSQL вместо Open. ExecSQL передает запрос для выполнения на сервер. В общем случае, если вы ожидаете, что получите от запроса данные, то используйте Open. В противном случае допускается использование ExecSQL, хотя его использование с Select не будет конструктивным. Листинг 6 содержит код, поясняющий сказанное на примере.
Листинг 6
Все приведенные выше примеры предполагают использования в ваших приложениях запросов. Они могут дать солидное основание для того, чтобы начать использовать в ваших приложениях TQuery. Но все же нельзя прогнозировать конец использования SQL в ваших приложених. Типичные серверы могут предложить вам другие характеристики, типа хранимых процедур и транзакций. В следующих двух секциях приведен краткий обзор этих средств.
[pagebreak]
3. Компонент TStoredProc
Хранимая процедура представляет собой список команд (SQL или определенного сервера), хранимых и выполняемых на стороне сервера. Хранимые процедуры не имеют концептуальных различий с другими типами процедур. TStoredProc наследуется от TDataset, поэтому он имеет много общих характеристик с TTable и TQuery. Особенно заметно сходство с TQuery. Поскольку хранимые процедуры не требуют возврата значений, те же правила действуют и для методов ExecProc и Open. Каждый сервер реализует работу хранимых процедур с небольшими различиями. Например, если в качестве сервера вы используете Interbase, хранимые процедуры выполняются в виде Select-запросов. Например, чтобы посмотреть на результаты хранимой процедуры, ORG_CHART, в демонстрационной базе данных EMPLOYEE, используйте следующих SQL-запрос:
При работе с другими серверами, например, Sybase, вы можете использовать компонент TStoredProc. Данный компонент имеет свойства для имен базы данных и хранимой процедуры. Если процедура требует на входе каких-то параметров, используйте для их ввода свойство Params.
4. TDatabase
Компонент TDatabase обеспечивает функциональность, которой не хватает TQuery и TStoredProc. В частности, TDatabase позволяет создавать локальные псевдонимы BDE, так что приложению не потребуются псевдонимы, содержащиеся в конфигурационном файле BDE. Этим локальным псевдонимом в приложении могут воспользоваться все имеющиеся TTable, TQuery и TStoredProc. TDatabase также позволяет разработчику настраивать процесс подключения, подавляя диалог ввода имени и пароля пользователя, или заполняя необходимые параметры. И, наконец, самое главное, TDatabase может обеспечивать единственную связь с базой данных, суммируя все операции с базой данных через один компонент. Это позволяет элементам управления для работы с БД иметь возможность управления транзакциями.
Транзакцией можно считать передачу пакета информации. Классическим примером транзакции является передача денег на счет банка. Транзакция должна состоять из операции внесения суммы на новый счет и удаления той же суммы с текущего счета. Если один из этих шагов по какой-то причине был невыполнен, транзакция также считается невыполненной. В случае такой ошибки, SQL сервер позволяет выполнить команду отката (rollback), без внесения изменений в базу данных. Управление транзакциями зависит от компонента TDatabase. Поскольку транзакция обычно состоит из нескольких запросов, вы должны отметить начало транзакции и ее конец. Для выделения начала транзакции используйте TDatabase.BeginTransaction. Как только транзакция начнет выполняться, все выполняемые команды до вызова TDatabase.Commit или TDatabase.Rollback переводятся во временный режим. При вызове Commit все измененные данные передаются на сервер. При вызове Rollback все изменения теряют силу. Ниже в листинге 7 приведен пример, где используется таблица с именем ACCOUNTS. Показанная процедура пытается передать сумму с одного счета на другой.
Листинг 7
И последнее, что нужно учесть при соединении с базой данных. В приведенном выше примере, TDatabase использовался в качестве единственного канала для связи с базой данных, поэтому было возможным выполнение только одной транзакции. Чтобы выполнить это, было определено имя псевдонима (Aliasname). Псевдоним хранит в себе информацию, касающуюся соединения, такую, как Driver Type (тип драйвера), Server Name (имя сервера), User Name (имя пользователя) и другую. Данная информация используется для создания строки соединения (connect string). Для создания псевдонима вы можете использовать утилиту конфигурирования BDE, или, как показано в примере ниже, заполнять параметры во время выполнения приложения.
TDatabase имеет свойство Params, в котором хранится информация соединения. Каждая строка Params является отдельным параметром. В приведенном ниже примере пользователь устанавливает параметр User Name в поле редактирования Edit1, а параметр Password в поле Edit2. В коде листинга 8 показан процесс подключения к базе данных:
Листинг 8
Этот пример показывает как можно осуществить подключение к серверу без создания псевдонима. Ключевыми моментами здесь являются определение DriverName и заполнение Params информацией, необходимой для подключения. Вам не нужно определять все параметры, вам необходимо задать только те, которые не устанавливаются в конфигурации BDE определенным вами драйвером базы данных. Введенные в свойстве Params данные перекрывают все установки конфигурации BDE. Записывая параметры, Delphi заполняет оставшиеся параметры значениями из BDE Config для данного драйвера. Приведенный выше пример также вводит такие понятия, как сессия и метод GetTableNames. Это выходит за рамки обсуждаемой темы, достаточно упомянуть лишь тот факт, что переменная session является дескриптором database engine. В примере она добавлена только для "показухи".
Другой темой является использование SQLPASSTHRU MODE. Этот параметр базы данных отвечает за то, как натив-команды базы данных, такие, как TTable.Append или TTable.Insert будут взаимодействовать с TQuery, подключенной к той же базе данных. Существуют три возможных значения: NOT SHARED, SHARED NOAUTOCOMMIT и SHARED AUTOCOMMIT. NOT SHARED означает, что натив-команды используют одно соединение с сервером, тогда как запросы - другое. Со стороны сервера это видится как работа двух разных пользователей. В любой момент времени, пока транзакция активна, натив-команды не будут исполняться (committed) до тех пор, пока транзакция не будет завершена. Если был выполнен TQuery, то любые изменения, переданные в базу данных, проходят отдельно от транзакции.
Два других режима, SHARED NOAUTOCOMMIT и SHARED AUTOCOMMIT, делают для натив-команд и запросов общим одно соединение с сервером. Различие между двумя режимами заключаются в передаче выполненной натив-команды на сервер. При выбранном режиме SHARED AUTOCOMMIT бессмысленно создавать транзакцию, использующую натив-команды для удаления записи и последующей попыткой осуществить откат (Rollback). Запись должна быть удалена, а изменения должны быть сделаны (committed) до вызова команды Rollback. Если вам нужно передать натив-команды в пределах транзакции, или включить эти команды в саму транзакцию, убедитесь в том, что SQLPASSTHRU MODE установлен в SHARED NOAUTOCOMMIT или в NOT SHARED.
5. Выводы
Delphi поддерживает множество характеристик при использовании языка SQL с вашими серверами баз данных. На этой ноте разрешите попрощаться и пожелать почаще использовать SQL в ваших приложениях.
В последние время в сети все чаще и чаще появляются некие калькуляторы. Например, многие хостинговые компании предлагает вам калькулятор для расчета стоимости услуг размещения сайта. Все что вам необходимо - выбрать тариф, дополнительные услуги, ввести продолжительность хостинга и нажать кнопку "Рассчитать". После чего вы моментально получаете результат прямо на странице сайта хостера. Причем сама страница не обновляется! Это простой пример динамического изменения кода.
Ладно, хватит разговоров, давайте перейдем непосредственно к примерам. Для начала самый простой. Создайте новый HTML файл и пропишите в нем следующий код:
Код:
Теперь сохраните файл и откройте его браузером. Вы увидите кнопку с надписью "Нажми на меня". Нажимайте, не бойтесь, баннеры не появятся ?. Что мы видим? Код изменился. Под кнопкой появилась надпись "Спасибо!". Содержание страницы изменилось. Но если вы загляните в файл с кодом, он неизменен. Как такое возможно? Все очень просто. Дело в том, что JS является client-side технологией. Т.е. он исполняется на машине посетителя, а не на сервере. А теперь давайте разберемся с кодом. Итак, с начала ничего нового не видим: форма с кнопкой, при клике на которую исполняется функция “test_change”. Сама функция содержит одну - единую строчку:
Код:
Это и есть команда JS на вставку. Все что остается добавить это место, куда делать вставку. Место мы обозначили идентификатором "resultat". Идентификатор вы можете изменять вольно по своему усмотрению. Теперь создаем новый слой и связываем его с идентификатором "resultat":
Код:
Ну как, неплохо? Сразу хочу вас обрадовать, динамически можно вставлять не только простой текст, но и HTML теги! А теперь рассмотрим более сложный пример. Создадим калькулятор, который по веденным данным подсчитает вашу месячную зарплату ?. Итак создайте новый HTML файл и наберите следующее:
Код:
Сохраняем файл и открываем его браузером. Что мы видим? Три поля для ввода и кнопку с надписью "Подсчитать", при клике на которую запускается функция "getmoney". Она получает введенные значения, вычисляет месячную зарплату и выводит ее в браузере. Введите значения и нажмите кнопку "Подсчитать". Обратите внимание на значение месячной зарплаты. А теперь измените одно или несколько введенных значений и снова нажмите кнопку "Подсчитать". Как вы видите новое значение заменило старое. Очень удобно. А можно, например, выводить новое значение под старым, для этого нужно изменить строчку
Код:
на
Код:
Теперь новые данные будут прибавляться к более ранним, и все они вместе будут выведены на экран. Обратите внимание на добавленный HTML тег в конце кода. Это перевод строки. Вот мы и протестировали использование HTML кода в динамически изменяемых страницах.
Конечно, калькуляторы нужны далеко не каждому сайту. И правильно, не стоит на одном зацикливаться. Подключите свое воображение. Возможность динамически добавлять HTML код открывает воистину огромный потенциал для разработчика. Конечно, меню на таком коде вряд ли сможет превзойти выпадающее меню JS - кликать надоест. А вот для экономии места и для организации пояснений к разным элементам сайта такие возможности JS идеально подходят. Простой пример - страница контактов на сайте компании. Там, как правило, размещена контактная информация компании, дистрибьюторов, представителей, разработчика сайта. Куча адресов, телефонов и e-mail'ов. Так и заблудиться можно. А вот если разместить ссылки "Компания", "Дистрибьюторы", "Представители", "Разработчик", посетитель быстро сориентируется и выберет нужную ссылку. Осталось только написать JS код, который при клике на ссылку выводит под ссылкой соответствующую информацию и убирал ранее выведеную. Многие могут возразить, мол можно сделать просто ссылку на нужный файл и не нужно динамическое изменение текущего. Но, во-первых, возможно посетитель заинтересован не одной ссылкой - ему придется возвращаться, а во-вторых, намного приятнее кликнуть и моментально (!!!) увидеть нужную информацию (загруженную вместе со страницей), чем ожидать загрузку очередной страницы. Давайте я дам простой примерчик, а разработка подобного кода останется вам как домашнее задание для закрепления материала. Итак, код:
Код:
При открытии файла, содержащего вышеуказанный код, в окне браузера можно будет увидеть две кнопки: "Включить" и "Выключить". При клике на первую из них функции "test_on_off" передается значение 1, а при клике на вторую - 0. В зависимости от полученного значения функция "test_on_off" либо выводит таблицу, либо убирает ее. Это лишь простой пример. Его можно немного улучшить, убрав одну кнопку и подправив код:
Код:
Теперь кнопка работает как выключатель: кликнул - включил, еще раз кликнул - выключил, снова кликнул - опять включил...
Если кто чего недопонимает - смело пишите. Ну, а если кому облом код набивать, тоже пишите, вышлю.
В общем теперь вы имеете немалый арсенал средств для сайтостроителя, так что удачной работы!
I. Вступление
II. Таблицы 1С и Excel.
III. Получение данных из Excel.
IV. Вывод данных в Excel.
V. Часто используемые методы для чтения/установки значений в Excel.
Вступление.
Многие знают, что Excel гораздо старше 1С. На мой взгляд, это очень успешный продукт, и нареканий о нем я не слышал. Excel прост и универсален. Он способен выполнять не только простые арифметические операции, но и сложные вычисления, построение графиков и т.п. Знаю примеры, когда организации до перехода на 1С вели часть бухгалтерии в Excel. Многие и сейчас параллельно используют две программы. В этой статье рассмотрим способы обмена данными между 1С и Excel.
Таблицы 1С и Excel.
Многие пользователи для удобства работы сохраняют таблицы 1С (печатные формы) в формате Excel (*.xls). После чего в полученном файле делают различные группировки, сортировки, вычисления и т.п. Связано это с тем, что в таблицах 1С нет такого огромного функционала как в таблицах Excel. Но в версии 1С 8.0 есть нововведения, делающих работу с таблицами более комфортной.
На сайте 1С (www.1C.ru) есть полезная программка, которая дает возможность открывать таблицы 1С в Excel и сохранять лист Excel как таблицу 1С. Это пригодится в том случае, если таблицу 1С не сохранили в формате Excel, а на том компьютере, где нужно открыть эту таблицу не установлена 1С. Да и постоянно помнить о том, что сохранить таблицу 1С нужно в формате Excel, не будет необходимости.
Полная информация о программе находится здесь.
Скачать программу можно здесь (архив zip 682 739 байт).
Замечание: В Excel разделителем дробной части считается символ ",". Поэтому перед сохранением таблицы 1С в формате Excel замените в ней другой разделитель (например ".") на ",". Иначе в Excel с этими числами не удастся произвести вычисления, или они вообще не будут отображаться как числа. Например, в таблице 1С "15.2" отобразится в Excel как "15.фев".
Получение данных из Excel.
Доступ из 1С к Excel производится посредством OLE. Например, код
позволит нам получить доступ через переменную "Эксель" к запущенному приложению Excel. А далее уже можно получить доступ к книге (файлу), листу и ячейке с данными. Далее примеры кода.
Открытие книги (файла):
ПутьКФайлу - полный путь к файлу книги Excel.
Выбор листа книги для работы с ним:
НомерЛиста - номер листа в книге, ИмяЛиста - имя листа в книге.
Получение значения ячейки листа:
НомерСтроки, НомерКолонки - номер строки и номер колонки, на пересечении которых находится ячейка.
Важно: не забывайте поле выполнения нужных действий добавлять код Эксель.Quit(); , иначе запущенный процесс останется незавершенным и будет занимать память и процессор компьютера.
Вывод данных в Excel.
Для вывода (выгрузки) данных в Excel необходимо либо открыть существующую книгу, либо создать новую, и выбрать рабочий лист для вывода данных. Открытие существующей книги описано выше, а для создания новой книги нужно использовать следующий код:
Так как при создании книги в Excel автоматически создаются листы (Сервис->Параметры->Общие->Листов в новой книге), то нужно лишь произвести выбор листа, с которым будет вестись работа:
либо добавить в книгу новый лист, если необходимо:
Следующим шагом будет установка значения ячейки:
НомерСтроки, НомерКолонки - номер строки и номер колонки, на пересечении которых находится ячейка.
И в конце нужно произвести запись созданной книги:
П
ПутьКФайлу - полный путь к файлу книги Excel (включая имя).
Важно: не забывайте, что в имени файлов не должно содержаться символов \ / : * ? " > < |.
Часто используемые методы для чтения/установки значений в Excel.
Эксель = СоздатьОбъект("Excel.Application");
Получение доступа к приложению Excel.
Мне приходится часто менять клиентов, потому что работаю удаленно. Сделал одному – иди к другому. А еще я продаю свои программы через Интернет. При имеющейся специфике работы, заметил одну странность: примерно в двадцати пяти процентов случаев, предприятие, оплатившее работу программиста и принявшее его работу, не пользуется ею.
Начну с примеров
Фирма, продающая компьютеры, купили внушительный комплект программного обеспечения, все своевременно оплатили, купили необходимое торговое оборудование... Мы, соответственно, все им установили и приготовились запускать. Остановились на этапе, когда сотрудники фирмы, ответственные за ввод в эксплуатацию нового программного комплекса, должны внести в информацию по имеющимся в отделах остаткам. Для справки – это примерно пара сотен наименований. Но на этом все работы по проекту остановились, потому что остатки не были внесены к намеченному сроку, ни через неделю после срока, ни через месяц. Не внесены они и до сих пор, хотя прошло уже пол года. Официально мы договорились, что клиент нам позвонит, когда сотрудники освободятся и найдут время внести остатки. Сами понимаете, на небольших фирмах менеджеры – по совместительству еще и продавцы, еще и грузчики, и кассиры…
Еще пример
Достаточно крупный комбинат решил автоматизировать учет обедов собственным сотрудникам в счет зарплаты. Систему подготовили, протестировали, поставили. Обучили их специалиста. Все как обычно. Недавно узнал, что конечный пользователь нашу систему не использует. Оказывается, по весьма банальной причине: на приобретение нового компьютера руководство не выделяет средств, а на имеющемся оказалось недостаточно мощности. В свое время мы указывали им на необходимость более мощного компьютера, но в силу не совсем понятных мне внутренних интриг, этот вопрос был замят на уровне IT-отдела. В результате, автоматизация стала не эффективной, и от использования новой программы решено было отказаться.
Третий пример
Производственная фирма заказала автоматизацию учета. От фирмы был назначен специалист – постановщик ТЗ и в будущем - внедренец. Работу сделали, сдали, провели обучение внедренца (на углубленное внедрение и обучение нами всех сотрудников не выделили бюджет). Я перезвонил клиенту через пол года, чтобы узнать, не было ли замечено каких-либо багов в работе системы. С удивлением услышал, что учет по-прежнему ведется в Excel-е, потому что на глубокое, самостоятельное освоение новой системы у сотрудников нет времени, а специалист, которого мы обучали, уволился…
Хотелось бы обобщить имеющийся, скромный опыт по таким случаям, и порассуждать на тему, когда автоматизация учета становится не эффективной по вине заказчика.
Уже из приведенных примеров можно сделать одно важное заключение: во всех трех случаях явно, что администрация не была заинтересована в результате. В первом – директор не захотел останавливать продажи даже не день, чтобы довести начатое до конца, во втором и третьем был урезан бюджет, и решили сэкономить там, где этого делать было нельзя.
1. Незаинтересованность руководства в результатах
Для меня всегда было загадкой, зачем руководство той или иной фирмы вообще тратится на автоматизацию, если отчетов в excel-е достаточно, и нет желания доводить начатое до конца? Чего дирекция хочет добиться? Дань моде? Надоел ноющий главбух? Решили, что что-то пора менять, но что менять – не выяснили? Стоит напомнить, что грамотно поставленная автоматизация учета в торгово-производственных фирмах способна увеличить прибыль и уменьшить затраты. Хорошая автоматизация окупается достаточно быстро, и уже скоро начинает приносить прибыль и экономию. Но если руководство не оценило перспектив автоматизации или, что еще хуже, считает, что новый стол из красного дерева топ-менеджеру важнее нового сервера сисадмину, то вряд ли на такой фирме автоматизация будет успешной.
2. Ограниченный бюджет
Как правило, из первого следует второе. Когда руководство не совсем отдает себе отчет в том, чего они ждут от автоматизации, тогда возникают идеи, наподобие: «а давайте пригласим студента, и он все сделает, как надо», или «давайте посадим главбуха на сервер»... Я, конечно, не против подработки студентов и не сомневаюсь в потенциале российского студенчества, но хочу лишь сказать о том, что для внедрения серьезной системы учета простого умения программировать очень мало. Хороший внедренец должен уметь просчитать возможные последствия выбора той или иной стратегии автоматизации. Это достаточно кропотливая работа, требующая, прежде всего, большого практического опыта, понимание не только специфики учета предприятия, но и его неочевидных нюансов. В конце концов, такая работа требует настойчивости, потому что часто решения внедренцев могут встретить сопротивление со стороны заказчика, и нужно уметь отстоять свои предложения, основываясь, опять же, на собственном опыте, защищая интересы сопротивляющегося клиента. Вряд ли какой-либо студент, понимающий, что занимается временным, не свойственным ему делом, способен на такое. Поэтому, считаю, что экономия на уровне исполнителя – это почти гарантия неудавшейся автоматизации.
Это же относится и к неоправданной экономии на оборудовании. Как правило, сбой системы происходит в самом слабом ее звене и в самый неподходящий момент… Помню, как у одного моего клиента, смотрящего «сквозь пальцы» на предложение обновить сервер, этот сервер вдруг однажды сгорел, когда бухгалтерия делала годовой отчет. Печально было то, что архивирование данных не велось должным образом, опять же, не смотря на рекомендации: директор считал покупку пишущего cd-room (в то время) – не особенно необходимыми затратами. Систему, конечно, восстановили. Но я помню, как бухгалтерии пришлось две недели работать чуть ли не по ночам, чтобы восстановить потерянные за год данные по первичным документам. Кстати, после этого случая руководство все-таки купило в то время жутко дорогой сервер с райд-массивом…
3. Тендер на откатах
Где-то встречал в сети примерную статистику, какой процент тендеров на IT услуги в России выигрывается за счет откатов ответственному лицу. Статистика – не утешительна. Печально, что на откаты попадают в основном крупные заказчики, где сумма договора внушительна, и руководство напрямую не занимается подбором исполнителя, а поручает это собственному специалисту, который не всегда бывает доволен уровнем своей заработной платы. Практика показывает, что при таком раскладе, все работы бывают выполнены в срок, все документы подписаны, но сотрудники фирмы остаются недовольны результатами и не могут использовать внедренную систему в планируемом объеме по разным причинам. Соответственно, руководство не имеет требуемой аналитической базы и начинает выяснять, в чем причина. Такие разбирательства затягиваются надолго, часто сопровождаются кадровыми движениями и, в конечном итоге, поисками того, кто бы систему довел до ума…
4. К вопросу о лидерах отрасли
Хотел бы привести еще один пример, достаточно типичный. Фирма готова тратить деньги на автоматизацию, но не сориентировалась на рынке IT-услуг и обратилась к кому-то очень известному. В результате затраты превысили все разумные пределы, а итог оказался не совсем ожидаемым, хотя, возможно, приемлемым с натяжкой.
К сожалению, это только при покупке автомобиля можно руководствоваться рекламными буклетами, и, если позволяют средства, выбирать самое последнее из модельного ряда. В сфере IT-услуг, как показывает практика, все далеко не так, особенно в сфере автоматизации на базе продуктов фирмы «1С» фирмами-франчайзи. Если исполнитель – не на уровне масштабов компании «Intel Corporation», то его раскрученность совсем может не соответствовать качеству предлагаемых им услуг, а объемы клиентской сети, требующей постоянного сопровождения, могут не позволить заниматься новым клиентом на должном уровне. На фоне этого, стоило бы вспомнить о небольших фирмах, менее раскрученных, а потому не выигравших тендер, которые были бы просто счастливы получить крупного заказчика IT-услуг, даже с меньшей суммой договора, и были готовы отдать все силы на то, чтобы клиент остался доволен. Амбиции небольших коллективов, уровень их специалистов и заинтересованность в результатах работы часто оказываются выше, чем у раскрученных, больших компаний. Небольшие фирмы не могут допустить в работе того, что позволят себе монополии, потому что любая неудача может грозить такой фирме банкротством.
Я назвал лишь четыре, пожалуй, основных фактора, когда автоматизация не достигает результатов, и присходит это, отчасти, по вине заказчика. Наверняка, имеются и другие причины, но корень проблем, на мой взгляд, следует искать, прежде всего, в неправильной позиции руководства компании, которая выражается или в непонимании, зачем нужна автоматизация, или в неправильно выбранной стратегии решения этого вопроса. Там, где решения принимаются трезво и взвешенно, где оценивается уровень специалиста, а не его раскрученность на рынке, где руководство четко понимает, чего оно ждет от автоматизации в итоге – там все будет нормально, чего всем и желаю…
Представляю на Ваш суд утилиту быстрого поиска по базе данных. Данная технология производит поиск по полям, преобразуя их значения в строки (все значения преобразуются в верхний регистр, включая действительные числа).
Данное решение может быть не самым быстрым, однако на поверку оно оказывается быстрее остальных, обнаруженных мною в Интернете (может вам повезет больше). Более того, представьте, что действительное значение какого-либо поля равно 4.509375354, а значение поиска равно 7, в этом случае утилита засчитает "попадание". Утилита удобна также тем, что она за один проход производит поиск более, чем в одном поле.
Это удобно, если у Вас имеются, к примеру, два поля с адресами. Это моя первая "серьезная" разработка, так как первое, с чем я столкнулся, изучая Delphi, стала необходимость включения процедуры поиска в любое приложение, работающее с базой данных. А так как поиск - вещь тоже сугубо специфическая, как и любое приложение, то мне пришлось побороть свой страх перед "крутым программированием" и попробовать написать свой поисковый механизм, удовлетворивший меня (и, надеюсь, других) своей скоростью и возможностью "мульти"-поиска по нескольким полям.
Я надеюсь, что он поможет тем программистам, кто часто сталкивается с подобными задачами. Технология довольно легка для понимания, но если у Вас возникли какие-либо вопросы, пошлите мне письмо электронной почтой, я буду рад Вам помочь. Посмотрев код, можно легко узнать поддерживаемые типы полей (добавить новые не составит проблем).
Эта заметка не имеет непосредственного отношения к DELPHI, уж извините :) Но получив в очередной раз письмо с предложение за два клика заработать $5000 я не выдержал, душа просит высказаться!
Я рассмотрю несколько вариантов заработка денег в internet с описанием, их плюсами и минусами. Сразу предупреждаю, это мое личное мнение, никак не претендую на глубину и всесторонность обзора.
1. Начнем с наиболее правильного и близкого нам программистам :) SHAREWARE.
Написание программы с целью ее продажи. Решаясь на подобное сначала все хорошенько обдумайте и взвесьте, зарабатывать на shareware можно и нужно, но… всегда есть проклятое "но" :) Для создания хорошо продаваемой программы вам придется не мало потрудиться. Срок от начала написания до реальных продаж вряд ли получится менее полугода. Вам придется много работать и главное думать. Здесь нет руководителя, который напишет Т.З. и скажет когда и что нужно сделать :( Все самому, а еще лучше команде. Одному человеку трудно быть одновременно хорошим программистом, генератором идей, дизайнером, маркетологом и т.д. и т.п. Лучше, если каждый будет заниматься тем, что умеет делать лучше всего. И тогда… по непроверенным данным ReGet получат более $50.000 в месяц! ;)
Как этого добиться? Здесь нет никаких строгих правил, все зависит от вашего таланта и, наверное, везения. Вот один из вариантов: выбрать направление программы, лучше, если это будет то, что требуется большому количеству людей каждый день в их постоянной работе за компьютером. Потратить с месяц или более, на сбор и анализ существующих подобных программ в интернете (трудно придумать что-то совсем уж уникальное :) обязательно уже есть аналоги, необходимо выяснить слабые и сильные стороны каждой программы и составить Т.З. для своей программы, включая туда самое лучшее. Кстати, не обязательно делать самостоятельную программу, это вполне может быть что-то прикладное к уже имеющимся. Например, каждый браузер умеет сам закачивать файлы из internet и тем не менее, "качалок" великое множество! Почему? Да потому что они удобнее в использовании и имеют дополнительные функции.
Далее самый плодотворный процесс - написание самой программы. На это уходит от месяца до года (больше не надо, а то она за это время бесконечно устареет :) По окончании написания программы, ее отладка и анализ, а действительно ли она так хороша, как предполагалось в начале?! ;) На этом этапе лучше выложить для скачивания бесплатную beta-версию на русском языке. И, зарегистрировавшись в русских каталогах, предлагать нашим тестировать новое чудо современных технологий! После чего, вы получите массу писем с ошибками и пожеланиями, все учитываете и дорабатываете, дорабатываете… На это может уйти даже больше, чем на написание основного кода программы. Когда считаете, что программа отшлифована и проверена на самых различных конфигурациях компьютеров, можно готовить английскую версию, выкладывать на сайт, регистрироваться в системах, которые помогут вам получать деньги от буржуев (например RegNow) и раскрутка вашего детища - регистрация в поисковых системах, а главное в каталогах для ShareWare программ, которых в инете великое множество. И с замиранием сердца ждать :) анализировать статистику заходов на ваш сайт, откуда приходят, почему с других мест не идут? Сколько людей пришло и "дошло" до скачивания и оплаты. На каком этапе вы потеряли клиента, почему? Все надо довести до идеала, клиенту нужно максимально упростить способ расставания с деньгами! :) Как видите, непосредственно программирование здесь занимает очень малую долю, и можно даже сказать, не главную! (Билл Гейтс ведь смог же продавать геморрой за деньги! :) :)
Рекомендую вам подписаться на рассылку российских шароварщиков swrus.com, узнаете много нового и полезного. А главное, общение с людьми, которые реально зарабатывают на этом! Плюсы:Это станет вашим основным заработком. Сумма, получаемая вами ежемесячно, ничем не ограничена, только вашим талантом! При удачной раскрутке, можно создавать свою фирму, становиться начальником, нанимая других программистов ;) Если на вас обратит внимание крупная западная фирма, то можно выгодно "продаться" :) Минусы: Вам придется долгое время вкалывать за красивую мечту. Никто, ничего не гарантирует. Вы с большой вероятностью можете в итоге оказаться у разбитого корыта :( Придется запастись терпением!
2. Создание сайта.
Вы создаете сайт, делаете его интересным для как можно большей доли посетителей интернета и как следствие, высокую посещаемость. После чего можно продавать рекламное место на своем сайте или зарабатывать через баннерные сети, что платят за показы или клики. Важно правильно выбрать тематику сайта, рекламодателям должно быть выгодно именно у вас размещать свою рекламу. Возьмем к примеру этот сайт (Мастера DELPHI), сайт сильно специфичен, рассчитан на очень малый процент людей в сети, мало того что именно программист, так еще и обязательно на DELPHI :) Потому добиться действительно высокой посещаемости его просто не реально. Но не это главное, кто из рекламодателей захочет здесь разместить рекламу? Ведь, понятно, его реклама должна ему же приносить деньги, т.е. чаще всего это или продажа своей программы, или привлечение целевой аудитории. Сайт русскоязычный, а русские не привыкли покупать программы, да и зачастую не на что! Вот и получается, что работаем мы над этим сайтом, только ради альтруизма и пользы вам, наши дорогие посетители :)
Или другой пример, сайт NoNaMe. Ему пол года, и за это время автор сайта добился блестящих результатов! (потому что сайт действительно интересен, всегда можно найти для себя что-то полезное. Рекомендую всем!) На данный момент до 9тыс. уникальных посетителей! Но… опять же, сайт специфичен, публикация кряков к программам оставляет весьма сомнительную вероятность того, что кто-то захочет рекламировать там свой продукт ;)
Лучше всего, конечно же, сайт рассчитанный на широкую публику: поисковые системы, каталоги, новости… игровые/развлекательные сайты здесь не лучшем положении (мой знакомый, автор сайта netcross.ru раскрутил его весьма хорошо, а сейчас практически забросил. Создал свою фирму по дизайну, и она за два месяца принесла денег больше чем за все время существования netcross.ru :) Плюсы:Широчайшее поле для творчества. Ваш доход ничем не ограничен. Интернет развивается бешенными темпами. И помните! Совсем недавно list.ru был продан за $5.000.000 !!! Вполне хватит на карманные расходы ;) Минусы: Вам придется в поте лица работать над своим сайтом и, как и в первом случае, большая вероятность остаться у разбитого корыта :(
3. Интернет услуги.
Создаете свою компанию по оказанию каких-либо интернет услуг: дизайн, интернет магазин, хостинг, регистрация, раскрутка и т.д. и т.п. Вполне реальный способ заработка, здесь нечего добавить. Практически в любом случае вы будете получать доход, доход лишь зависит от вашего желания работать и от того, откуда у вас растут руки :) Лично я напрямую связан с предоставлением хостинга российским компаниям, и со всей ответственностью заявляю, на хостинге можно и нужно зарабатывать. Помните, русский интернет сейчас развивается очень быстро, и потребность в различных видах услуг велика. Плюсы: Вы получаете реальные деньги за реальную работу. Все сводится только к поиску и привлечению людей, которым ваши услуги необходимы. Минусы: Зачастую требует начальных капиталовложений. Здесь нет халявы, не получится почивать на лаврах (как при удачном раскладе в первых двух пунктах), работать, работать и еще раз работать :)
На этом позвольте закончить вторую часть. Это не все о заработке, возможно я продолжу этот цикл, если вам конечно интересно :)
Еще недавно устройств поддерживающих Wi-Fi было не так уж много это компьютеры да точки доступа. В настоящее время с Wi-Fi могут работать сотовые телефоны, веб-камеры, мультимедиа-центры, проекторы и принтеры!
Многим из этих устройств не нужны точки доступа, они работают от передатчика подключенного к компьютеру. Имея такое оборудование многие забыли что такое спотыкаться о провода опутывающие квартиру.
Мультимедиа в домашней Wi-Fi сети или какие бывают беспроводные устройства.
Еще недавно устройств поддерживающих Wi-Fi было не так уж много это компьютеры да точки доступа. В настоящее время с Wi-Fi могут работать сотовые телефоны, веб-камеры, мультимедиа-центры, проекторы и принтеры!
Многим из этих устройств не нужны точки доступа, они работают от передатчика подключенного к компьютеру. Имея такое оборудование многие забыли что такое спотыкаться о провода опутывающие квартиру.
Веб-камеры: «шеф, а я вас вижу!»
Веб-камер работающих по интерфейсу Wi-Fi выпускается большое количество. Такое устройство можно установить в любом месте квартиры или офиса и наблюдать за происходящим через специальную интернет-страничку с домашней локальной сети.
Самые доступные устройства этой категории делает компания D-Link. Это веб-камеры D-Link DCS-G900 и D-Link — DCS-5300G.
DCS-G900 может автоматически включаться при обнаружении на подведомственной территории чьего-то движения. Очень полезная функция при установке домашней охранной системы.
Преимущество D-Link — DCS-5300G перед DCS-G900 заключается в подвижной головке с управляемым приводом вращения. Благодаря этому устройство можно направлять практически в любую точку пространства.
Единственный минус этих веб-камер малое разрешение обеих моделей — они могут передавать видео в разрешении лишь 320x240 точек, зато с частотой 30 кадров в секунду.
Фотоаппараты: передай мгновение.
Использование Wi-Fi в фотоаппаратах более чем обосновано — можно передавать картинки на компьютер, не подсоединяя ненавистные провода и не вытаскивая флэш-карту. Среди таких устройств можно выделить Nikon Coolpix L4.
Это компактная фотокамера с 4-мегапиксельным сенсором и трехкратным оптическим зумом. Есть у нее возможность макросъемки и записи видео в разрешении до 640x480 с частотой 15 кадр./с. Для хранения снимков применяются карточки памяти SD.
Единственный недостаток фотоаппарата в том, что для передачи кадров необходимо устанавливать дополнительные программы — в гостях воспользоваться беспроводными коммуникациями не удастся.
Еще одно устройство, оснащенное беспроводными коммуникациями, — это Canon Digital IXUS Wireless — 5-мегапиксельная фотокамера с 3-кратным оптическим зумом. Она способна записывать видео в разрешении до 640x480 точек и с частотой до 60 кадров в секунду. В качестве хранилища информации также используются карты SecureDigital.
Принтеры: твердые копии цифрового мира.
Одним из представителей таких устройств является принтер HP DeskJet 6983. В нем используется классическая термическая струйная технология с разрешением до 4800x1200 dpi и четырьмя картриджами, максимальный формат печати — лист A4.
Принтер быстр — в режиме черно-белой печати может выдавать до 36 страниц в минуту, а на цветной до 27 страниц в минуту. Устройство можно подключать как по интерфейсу USB, так и с помощью Wi-Fi. В последнем случае оно, увы, может работать только в режиме Ad-Hoc — при непосредственном контроле с компьютера.
Самым признанным считается офисный лазерный принтер с поддержкой Wi-Fi Epson AcuLaser C1900. Устройство позволяет печатать с разрешением 600x600 dpi. Скоростью оно, правда, не большая — до 4 страниц в минуту в режиме цветной печати, и до 16 — в черно-белой, — зато качество выше всяких похвал.
VoIP: бесплатные слова.
Сейчас в глобальной сети существует множество компаний, дающих возможность бесплатно или очень дешево переводить звонки из интернета на городские и мобильные телефоны. И если в квартире есть Интернет, то грех этим не воспользоваться для почти бесплатных звонков по всему миру.
Конечно, пользоваться этими сервисами можно и с помощью проводной гарнитуры или микрофона и наушников, но беспроводная связь намного удобнее и комфортней.
Например такой смартфон с поддержкой Wi-Fi, I-Mate SP5m. Он снабжен высококачественным цветным экраном с разрешением 320x240 точек, может работать в сетях GSM всех четырех диапазонов и использоваться в качестве MP3-плеера (информация хранится на карточках TransFlash). Смартфон по умолчанию работает в режиме автоматического роуминга — в «безинтернетном» месте он звонит по GSM, в хот-спотах же переключается на VoIP-телефонию.
Естествинно это не единственный смартфон. Для бесплатного разговора можно применять любой КПК или смартфон, в котором есть Wi-Fi, — например, HP iPAQ hx2415, Fujitsu-Siemens Pocket LOOX 710, Dell Axim X50v, Tungsten C.
Мультимедийные центры: кино и радио.
Лучше всего отдохнуть и расслабиться в любимой квартире, с бутылкой пива в руке, конечно за просмотром хорошего фильма. В этом поможет мультимедийный центр D-Link DSM-320. Он обеспечивает доступ к видеоархиву на компьютере из любой комнаты. Достаточно подсоединить к видеовыходу телевизор, а к аудио — звуковую систему, и можно наслаждаться кино или музыкой, хранящимися на жестком диске компьютера. Поддерживаются форматы звука MP3, WMA и WAV, видео — MPEG1/2/4, DIVX, QuickTime и Xvid, а также графические файлы — JPEG, JPEG2000, TIFF, GIF, BMP или PNG. Можно также прослушивать онлайновые радиостанции.
Есть еще боле продвинутая модернизация DSM-300 — это D-Link DSM-320RD. В его состав также входит собственный DVD-проигрыватель и кард-ридер SD — чтобы в случае, если диск оказывается под рукой, не бежать в другую комнату, дабы установить его в ПК. Увы, подобные недорогие устройства есть только у D-link.
Более дорогие устройства это Archos Pocket Media Assistant PMA430. Этот мультимедийный плеер работает на встроенной операционной системе Linux и позволяет проигрывать видео и аудио в самых разнообразных форматах. Его характеристики чем-то схожи с D-Link DSM-320RD — вот только DVD-привод, увы, отсутствует.
Самое полное решение проблемы домашнего кинотеатра — использование проектора. Для этих целей подходит Benq MP620. Это устройство выдает яркость в 2200 лм, контрастность картинки составляет 2000:1. Поддерживается разрешение XGA (1024x768).
И самым экзотическим устройством считается Wi-Fiрадио от Acoustic Energy. Посредством Wi-Fi устройство соединяется с сервером Reciva, который предоставляет список доступных интернет-станций и соединяет с выбранной.
По сравнению с обычным радио, которое имеет жесткий временной график, интернет-вещание позволяет заказать нужную передачу на любое удобное время. Кроме того, радио можно использовать в качестве клиентского модуля для проигрывания музыки с ПК.
Компьютер: свобода мышам.
И еще одно похожее устройство это Wireless VGA Extender (его другое название — LongView VGA Extender) но работающее не по технологии Wi-Fi.
Устройство состоит из двух частей — к одному блоку, внешним видом более всего напоминающему пресловутую точку доступа, можно подключить монитор, мышку и клавиатуру, второй устанавливается в сам компьютер. После этого системный блок можно запихать подальше под стол и забыть о нем.
Правда у этого устройства много недостатков — так, монитор можно подключить только по D-Sub, причем максимальное разрешение составит всего 1024x768, а мышки и клавиатуры поддерживаются только с интерфейсом PS/2.
Как только появляется желание перейти с Windows на другие платформы или на веб-приложения, возникает проблема: там же нет «Фотошопа»! Этот популярный графический пакет благодаря пиратам есть сейчас на большинстве компьютеров в СНГ. И найти альтернативу этой программе сложно. Но как мы используем такую мощную программу? В основном это изменить размеры, подкорректировать яркость, иногда убрать лишние детали, да отправить на е-мейл подружке.
Лучшие графические редакторы, написанные на Flash.
Как только появляется желание перейти с Windows на другие платформы или на веб-приложения, возникает проблема: там же нет «Фотошопа»! Этот популярный графический пакет благодаря пиратам есть сейчас на большинстве компьютеров в СНГ. И найти альтернативу этой программе сложно. Но как мы используем такую мощную программу? В основном это изменить размеры, подкорректировать яркость, иногда убрать лишние детали, да отправить на е-мейл подружке.
Разве нужен для этого полноценный Photoshop? Конечно же, нет, если только вы не дизайнер-профессионал высокого класса. Поэтому найти аналог будет намного проще. Но искать аналог среди настольных программ скучно и неинтересно. Мы живем в век Web 2.0 и поэтому искать аналоги будем среди веб-приложений. Развитие графических возможностей Flash позволяет получить весьма интересные результаты. Описываемые редакторы не станут полной заменой «Фотошопа», но для небольших фотокоррекций они пригодятся.
72photos
Это скорее не редактор а фотогалерея с возможностью слегка подредактировать сохраненные снимки. Функции рисования здесь нет. Можно наложить эффекты на снимок, подправить цветопередачу, яркость и обрезать лишнее. Также есть размытие/резкость и несколько стандартных фильтров. Все достаточно среднее, ничего выдающегося, но как интересное применение возможностей Flash подойдет. Из полезных особенностей стоит отметить возможность работы с картинками, сохраненными на других фотохостингах, впрочем, из очень небольшого списка. FotoFlexer
Редактор, обладающий рядом неоспоримых достоинств, но есть и некоторые недостатки.
Это абсолютный лидер по реализованным функциям. Он поддерживает большое количество фотохостингов, с которых можно загрузить фотографии для редактирования, возможна загрузка просто по URL, что позволяет редактировать любую картинку, также есть загрузка картинок с компьютера пользователя. Чтобы сохранять файл, куда вам надо, придется регистрироваться. И просто на компьютер файл не отдадут. Придется выдирать с какой-то файлопомойки. Или регистрироваться. Мелочь, но неприятно.
Огромное количество эффектов и инструментов. Можно рисовать, накладывать эффекты, трансформировать картинку. Есть готовые для добавления графические примитивы, позволяющие создавать фотографии со вставкой лиц друзей. Здесь же можно и рамочки прикрутить и постер оформить. В общем, раздолье для бытового фотографа. Правда подписать фотографии не получится, русский текст программа не понимает.
Есть инструменты и для более серьезной публики. Сложные трансформации, инструменты выделения и перекрашивания, аналогичные привычным инструментам, даже кое-какая поддержка слоев.
Аналогов по функциональности среди онлайн-сервисов на сегодня нет.
Phoenix
Редактор с продуманным интерфейсом. Без регистрации работать отказывается. Зато потом способен открывать файлы не только со своего сервера и компьютера пользователя, но и со сторонних сервисов и по URL. Неплохой набор фильтров и эффектов. Есть полноценное рисование с возможностью русских надписей. Поддерживаются слои. Правда иногда серверная часть дает сбои при сохранении. Да и само приложение могло бы работать побыстрее. В остальном же отличный редактор.
Photoshop Express
Эта программа считается аналогом настольного Photoshop от создателей Photoshop. Но на самом деле она больше напоминает вышеупомянутый редактор 72photos, только более качественно исполненный. Это фотохостинг, можно просматривать галереи других пользователей, комментировать их. При этом интеграции со сторонними сервисами нет, работать можно только с фотографиями, загруженными с компьютера пользователя. Возможности редактора скромны, изменение размеров, повороты, немного эффектов. Рисования нет.
И все-таки, имеющиеся функции реализованы качественно, работает все очень быстро. Сказывается, что авторы разрабатывали не только Photoshop, но и собственно Flash. Получившимся продуктом приятно пользоваться. И, вероятней всего, следует ожидать дальнейшего развития. PicMagick
Самый элементарный и примитивный из рассматриваемых редакторов. Позволяет только загрузить картинку с компьютера, наложить стандартный набор эффектов и получить обратно свою фотографию. Возможностей сохранения на сервере, рисования и интеграции с другими сервисами нет. Минимализм в чистом виде. Даже регистрации нет. Редактор сразу готов к работе. При этом особой скоростью работы не отличается. Единственная особенность, выделяющая из ряда прочих редакторов — фильтр коррекции кожи. Впрочем, достоинство сомнительное, того же можно добиться и другими инструментами. Picnik
Этим редактором пользуются на популярном фотохостинге Flickr в качестве стандартного. Пользоваться этим редактором могут все желающие. Даже без регистрации. Закачать картинки можно с компьютера, из популярного фотохостинга или блога, с любого URL. Редактор понимает не только стандартные web-типы графики, но и большое количество других распространенных форматов. По этому параметру Picnik — абсолютный лидер.
Хорош он и в реализации. Долгий старт приложения компенсируется большим количеством эффектов и инструментов. Несколько уступая FotoFlexer, он опережает остальных конкурентов. Вот только рисования в чистом виде нет. Можно только накладывать готовые графические примитивы. И ввести русский текст нельзя, получаются сплошные вопросительные знаки.
Сохранять полученный результат можно тоже как у себя на компьютере, так и на популярных хостингах. А можно и сразу на е-мейл. Причем в разнообразных форматах. Pixer.us
Правда это в общем-то и не совсем Flash-редактор. Он написан на Javascript, что уже само по себе интересно. Да и на полноценный редактор сервис не тянет. Вы можете загрузить фотографию со своего компьютера, применить к ней ряд эффектов и сохранить обратно. И все. Работает все достаточно быстренько, но без изысков. Рисования нет. Но как демонстрация возможностей безфлешевых технологий, редактор интересен. К примеру, если сравнивать его с Picmagick, то поединок будет как минимум равным.
Pixlr
Это редактор в чистом виде, без хостинга. Зато есть API, что возможно позволит встраивать редактор в сторонние приложения. Редактор один из семейства клонов фотошопа. Есть русская локализация, чего нет у многих других редакторов. Соответственно, русские надписи делать тоже можно.
Отличная оптимизация работы. Все открывается быстро. Отличный функционал. Есть даже столь любимый Magic Wand. Слои и фильтры тоже на месте, хотя набор инструментов мог бы быть побольше. Впрочем, все основные примочки на месте. Да и интерфейс опять-таки навевает воспоминания о фотошопе. Приятный в работе, продуманный редактор.
Splashup
Очередной гибрид фотохостинга и неплохого редактора. Есть слои, эффекты, полноценное рисование. Русский язык не работает, а вот все остальное на достойном уровне. Можно загрузить свою картинку с компьютера, из интернета (поддержка фотохостингов и прямых URL), отредактировать и сохранить в различных местах.
Очень удобный, приятный интерфейс, отличная скорость работы. Достойный представитель онлайн-редакторов, пытающихся копировать Photoshop.
SUMO Paint
Солидный редактор, близок к настольному приложению как по внешнему виду, так и по функциональному. Правда, оторван от большого интернета. Ни загрузки по URL, ни интеграции с другими сервисами нет. Только аккаунт на собственном сервере и загрузка с компьютера (которая работает не очень уверенно).
Зато функционал впечатляет. Тут нет приевшихся рамочек и цветочков, только серьезные инструменты. Полноценная поддержка слоев, разнообразные эффекты и фильтры. Чем-то напоминает старые версии Photoshop. Очень достойная разработка. И даже поддержка русских шрифтов в наличии. Если поправят проблемы с загрузкой фотографий, будет замечательно.
Конечно неодин из онлайн-редакторов не составит конкуренцию Photoshop. Если в базовых инструментах как-то еще можно соперничать, то когда речь заходит о сложных фильтрах, Photoshop в не конкуренции. А представить себе в онлайн варианте пакетную обработку или плагины и вовсе невозможно. И, конечно, профессионалы не откажутся от привычного инструмента. Зато для обычных пользователей возможности онлайн-редакторов уже сегодня могут вполне пригодиться.
И будущее у этого направления весьма светлое.
Самым распространенным и популярным из профессиональных графических редакторов считается Adobe Photoshop. Но многим профессионалам все возможности «Фотошопа» не нужны в полном объеме, а цена его довольно высокая. Вот и приходится искать более дешевые но с профессиональными возможностями. Таких редакторов в настоящее время существует достаточно много. Один из них Photo Pos Pro от компании Power of Software, у которого есть все возможности профессионального графического редактора.
Photo Pos Pro еще один профессиональный графический редактор.
Самым распространенным и популярным из профессиональных графических редакторов считается Adobe Photoshop. Но многим профессионалам все возможности «Фотошопа» не нужны в полном объеме, а цена его довольно высокая. Вот и приходится искать более дешевые но с профессиональными возможностями. Таких редакторов в настоящее время существует достаточно много. Один из них Photo Pos Pro от компании Power of Software, у которого есть все возможности профессионального графического редактора.
Сколько существует графических редакторов столько же и существует логик работы с ними. С Photo Pos Pro придется немного повозиться, вникая в его логику. К примеру, масштабировать изображение по "горячим" клавишам Ctrl+ и Ctrl– не получится, зато можно масштабировать с помощью левой и правой кнопок мыши, что тоже довольно удобно. Так же отсутствует типовой для всех графических редакторов инструмент Levels в чистом виде. Привычные в других программах операции здесь выполнялись несколько по-другому, и поэтому приходилось внимательно изучать файл справки. И, к сожалению, обращение к справке требует знаний английского языка — программа не локализована.
Когда же немного освоишься в программе, начинаешь понимать, насколько ее интерфейс удобен. Иконки поначалу кажутся маленькими, но привыкаешь к ним быстро. Оригинально выполнены окна панелей инструментов. Их всего два: менеджер слоев и собственно панель инструментов. Менеджер слоев — постоянная панель, а вот панель инструментов меняется в зависимости от выбранного инструмента. Обе панели автоматически сворачиваются и разворачиваются при наведении на них указателя мыши. Это очень удобно, так как панель в развернутом виде нужна только при настройке параметров инструмента, а в остальное время она мешает работе. Автоматическое сворачивание панелей до полосы с названием панели позволяет максимально сосредоточиться на творческой деятельности. Впрочем, при необходимости можно закрепить панели в развернутом состоянии.
Довольно-таки удобно реализован и инструмент выбора цвета. Он находится на правом крае рабочей области программы и включает в себя кроме инструмента выбора цвета еще и возможности по управлению градиентом заливки, текстурой и шаблонами. Здесь также нашлось некоторое отклонение от стандартных правил, хотя инструмент очень удобен. В соответствии с этими правилами цвет фона (background) располагается на инструментах выбора цвета за цветом инструмента (foreground). В Photo Pos Pro все наоборот, и это на первых порах сбивает с толку, но потом привыкаешь и к этому.
Еще удобно сделано в интерфейсе поддержка вкладок. Некоторых редакторах несколько открытых изображений показываются через отдельные окна, что затрудняет навигацию между ними, если открыто много картинок. При использовании механизмов вкладок такая навигация упрощается. Точно так же в виде вкладки может быть встроенный просмотрщик картинок. В самом просмотрщике можно получить полную информацию о любой из фотографий, как о самом файле, так и Exif.
Есть возможность использования фонов, которые можно просмотреть через специальный инструмент Themes Background. Темы фона в этом каталоге разбиты на пять категорий, и общее их количество не очень велико. Хотя можно загрузить бесплатные темы с сайта либо поместить свои картинки в папку Pictures каталога программы, так как в качестве фона используются картинки в обычных графических форматах. Аналогично можно поступить с масками, шаблонами, кистями, текстурами, подкладывая собственные образцы в соответствующие папки. А вот с рамками так не получится, так как для рамок используется собственный формат.
В арсенале инструментов для обработки изображений у Photo Pos Pro есть практически все:
• инструменты выделения, поворота и отображения;
• инструменты перемещения, обрезки и трансформации;
• разнообразные виды кистей, шаблоны, текстуры, градиенты;
• инструменты создания различных форм и линий;
• инструменты пакетной, ручной и автоматической цветокоррекции;
• разнообразные фильтры, маски и эффекты;
• инструменты добавления рамок, текста;
• возможность работы со слоями.
Удобство работы с инструментами все же не такое высокое, как в иных редакторах. Не совсем удобны маленькие и не изменяемые в размерах окна фильтров. В них получаются очень мелкие превьюшки обрабатываемых изображений, поэтому приходится использовать кнопку Preview, либо включать режим AutoPrewiew, который отображает на самом изображении вносимые изменения. А на полную обработку картинки требуются время и вычислительные ресурсы. На слабых компьютерах это будет серьезно мешать дизайнеру. С этой точки зрения системные требования к компьютеру явно занижены разработчиками.
Механизмы эффектов, фильтров, инструментов цветокоррекции работают довольно хорошо. Реализовать какую-нибудь задумку не сможет разве что ну очень "креативный" дизайнер. Набор фильтров богат, хотя совсем уж оригинальных не нашлось. Также не нашлось механизма подключения плагинов сторонних разработчиков, такая функция не помешала бы.
В Photo Pos Pro есть упрощенный инструмент нарезки изображений для Веба: HTML Image Mapper. К нему бы добавить инструмент оптимизации самого изображения для Веба по размеру файла, который здесь отсутствует — и вовсе было бы замечательно.
А в общем Photo Pos Pro — довольно удобный графический редактор, который претендует на уровень профессионального. К нему, конечно, нужно привыкать, но, однажды привыкнув, вы сможете на довольно высоком уровне обрабатывать графический материал, получая профессиональные результаты.
Системные требования:
• операционная система Windows 98/Me/XP/Vista;
• процессор с частотой 350 МГц и выше;
• 256 Mб оперативной памяти;
• 300 Mб свободного места на жестком диске;
• 16-битная цветопередача;
• разрешение монитора 800x600 пикселей.
Сеть всегда объединяет несколько абонентов, каждый из которых имеет право передавать свои пакеты. Но, как уже отмечалось, по одному кабелю одновременно передавать два (или более) пакета нельзя, иначе может возникнуть конфликт (коллизия), который приведет к искажению либо потере обоих пакетов (или всех пакетов, участвующих в конфликте). Значит, надо каким-то образом установить очередность доступа к сети (захвата сети) всеми абонентами, желающими передавать. Это относится, прежде всего, к сетям с топологиями шина и кольцо. Точно так же при топологии звезда необходимо установить очередность передачи пакетов периферийными абонентами, иначе центральный абонент просто не сможет справиться с их обработкой.
В сети обязательно применяется тот или иной метод управления обменом (метод доступа, метод арбитража), разрешающий или предотвращающий конфликты между абонентами. От эффективности работы выбранного метода управления обменом зависит очень многое: скорость обмена информацией между компьютерами, нагрузочная способность сети (способность работать с различными интенсивностями обмена), время реакции сети на внешние события и т.д. Метод управления – это один из важнейших параметров сети.
Тип метода управления обменом во многом определяется особенностями топологии сети. Но в то же время он не привязан жестко к топологии, как нередко принято считать.
Методы управления обменом в локальных сетях делятся на две группы:
* Централизованные методы, в которых все управление обменом сосредоточено в одном месте. Недостатки таких методов: неустойчивость к отказам центра, малая гибкость управления (центр обычно не может оперативно реагировать на все события в сети). Достоинство централизованных методов – отсутствие конфликтов, так как центр всегда предоставляет право на передачу только одному абоненту, и ему не с кем конфликтовать.
* Децентрализованные методы, в которых отсутствует центр управления. Всеми вопросами управления, в том числе предотвращением, обнаружением и разрешением конфликтов, занимаются все абоненты сети. Главные достоинства децентрализованных методов: высокая устойчивость к отказам и большая гибкость. Однако в данном случае возможны конфликты, которые надо разрешать.
Существует и другое деление методов управления обменом, относящееся, главным образом, к децентрализованным методам:
* Детерминированные методы определяют четкие правила, по которым чередуются захватывающие сеть абоненты. Абоненты имеют определенную систему приоритетов, причем приоритеты эти различны для всех абонентов. При этом, как правило, конфликты полностью исключены (или маловероятны), но некоторые абоненты могут дожидаться своей очереди на передачу слишком долго. К детерминированным методам относится, например, маркерный доступ (сети Token-Ring, FDDI), при котором право передачи передается по эстафете от абонента к абоненту.
* Случайные методы подразумевают случайное чередование передающих абонентов. При этом возможность конфликтов подразумевается, но предлагаются способы их разрешения. Случайные методы значительно хуже (по сравнению с детерминированными) работают при больших информационных потоках в сети (при большом трафике сети) и не гарантируют абоненту величину времени доступа. В то же время они обычно более устойчивы к отказам сетевого оборудования и более эффективно используют сеть при малой интенсивности обмена. Пример случайного метода – CSMA/CD (сеть Ethernet).
Для трех основных топологий характерны три наиболее типичных метода управления обменом.
Управление обменом в сети с топологией звезда
Для топологии звезда лучше всего подходит централизованный метод управления. Это связано с тем, что все информационные потоки проходят через центр, и именно этому центру логично доверить управление обменом в сети. Причем не так важно, что находится в центре звезды: компьютер (центральный абонент), как на рис. 1.6, или же специальный концентратор, управляющий обменом, но сам не участвующий в нем. В данном случае речь идет уже не о пассивной звезде (рис. 1.11), а о некой промежуточной ситуации, когда центр не является полноценным абонентом, но управляет обменом. Это, к примеру, реализовано в сети 100VG-AnyLAN.
Самый простейший централизованный метод состоит в следующем.
Периферийные абоненты, желающие передать свой пакет (или, как еще говорят, имеющие заявки на передачу), посылают центру свои запросы (управляющие пакеты или специальные сигналы). Центр же предоставляет им право передачи пакета в порядке очередности, например, по их физическому расположению в звезде по часовой стрелке. После окончания передачи пакета каким-то абонентом право передавать получит следующий по порядку (по часовой стрелке) абонент, имеющий заявку на передачу (рис. 4.8). Например, если передает второй абонент, то после него имеет право на передачу третий. Если же третьему абоненту не надо передавать, то право на передачу переходит к четвертому и т.д.
Централизованный метод управления обменом в сети с топологией звезда
Рис. 4.8. Централизованный метод управления обменом в сети с топологией звезда
В этом случае говорят, что абоненты имеют географические приоритеты (по их физическому расположению). В каждый конкретный момент наивысшим приоритетом обладает следующий по порядку абонент, но в пределах полного цикла опроса ни один из абонентов не имеет никаких преимуществ перед другими. Никому не придется ждать своей очереди слишком долго. Максимальная величина времени доступа для любого абонента в этом случае будет равна суммарному времени передачи пакетов всех абонентов сети кроме данного. Для топологии, показанной на рис. 4.8, она составит четыре длительности пакета. Никаких столкновений пакетов при этом методе в принципе быть не может, так как все решения о доступе принимаются в одном месте.
Рассмотренный метод управления можно назвать методом с пассивным центром, так как центр пассивно прослушивает всех абонентов. Возможен и другой принцип реализации централизованного управления (его можно назвать методом с активным центром).
В этом случае центр посылает запросы о готовности передавать (управляющие пакеты или специальные сигналы) по очереди всем периферийным абонентам. Тот периферийный абонент, который хочет передавать (первый из опрошенных) посылает ответ (или же сразу начинает свою передачу). В дальнейшем центр проводит сеанс обмена именно с ним. После окончания этого сеанса центральный абонент продолжает опрос периферийных абонентов по кругу (как на рис. 4.8). Если желает передавать центральный абонент, он передает вне очереди.
Как в первом, так и во втором случае никаких конфликтов быть не может (решение принимает единый центр, которому не с кем конфликтовать). Если все абоненты активны, и заявки на передачу поступают интенсивно, то все они будут передавать строго по очереди. Но центр должен быть исключительно надежен, иначе будет парализован весь обмен. Механизм управления не слишком гибок, так как центр работает по жестко заданному алгоритму. К тому же скорость управления невысока. Ведь даже в случае, когда передает только один абонент, ему все равно приходится ждать после каждого переданного пакета, пока центр опросит всех остальных абонентов.
Как правило, централизованные методы управления применяются в небольших сетях (с числом абонентов не более чем несколько десятков). В случае больших сетей нагрузка по управлению обменом на центр существенно возрастает.
Управление обменом в сети с топологией шина
При топологии шина также возможно централизованное управление. При этом один из абонентов ("центральный") посылает по шине всем остальным ("периферийным") запросы (управляющие пакеты), выясняя, кто из них хочет передать, затем разрешает передачу одному из абонентов. Абонент, получивший право на передачу, по той же шине передает свой информационный пакет тому абоненту, которому хочет. А после окончания передачи передававший абонент все по той же шине сообщает "центру", что он закончил передачу (управляющим пакетом), и "центр" снова начинает опрос (рис. 4.9).
Централизованное управление в сети с топологией шина
Рис. 4.9. Централизованное управление в сети с топологией шина
Преимущества и недостатки такого управления – те же самые, что и в случае централизованно управляемой звезды. Единственное отличие состоит в том, что центр здесь не пересылает информацию от одного абонента к другому, как в топологии активная звезда, а только управляет обменом.
Гораздо чаще в шине используется децентрализованное случайное управление, так как сетевые адаптеры всех абонентов в данном случае одинаковы, и именно этот метод наиболее органично подходит шине. При выборе децентрализованного управления все абоненты имеют равные права доступа к сети, то есть особенности топологии совпадают с особенностями метода управления. Решение о том, когда можно передавать свой пакет, принимается каждым абонентом на месте, исходя только из анализа состояния сети. В данном случае возникает конкуренция между абонентами за захват сети, и, следовательно, возможны конфликты между ними и искажения передаваемой информации из-за наложения пакетов.
Существует множество алгоритмов доступа или, как еще говорят, сценариев доступа, порой очень сложных. Их выбор зависит от скорости передачи в сети, длины шины, загруженности сети (интенсивности обмена или трафика сети), используемого кода передачи.
Иногда для управления доступом к шине применяется дополнительная линия связи, что позволяет упростить аппаратуру контроллеров и методы доступа, но заметно увеличивает стоимость сети за счет удвоения длины кабеля и количества приемопередатчиков. Поэтому данное решение не получило широкого распространения.
Суть всех случайных методов управления обменом довольно проста.
Если сеть свободна (то есть никто не передает своих пакетов), то абонент, желающий передавать, сразу начинает свою передачу. Время доступа в этом случае равно нулю.
Если же в момент возникновения у абонента заявки на передачу сеть занята, то абонент, желающий передавать, ждет освобождения сети. В противном случае исказятся и пропадут оба пакета. После освобождения сети абонент, желающий передавать, начинает свою передачу.
Возникновение конфликтных ситуаций (столкновений пакетов, коллизий), в результате которых передаваемая информация искажается, возможно в двух случаях.
* При одновременном начале передачи двумя или более абонентами, когда сеть свободна (рис. 4.10). Это ситуация довольно редкая, но все-таки вполне возможная.
* При одновременном начале передачи двумя или более абонентами сразу после освобождения сети (рис. 4.11). Это ситуация наиболее типична, так как за время передачи пакета одним абонентом вполне может возникнуть несколько новых заявок на передачу у других абонентов.
Существующие случайные методы управления обменом (арбитража) различаются тем, как они предотвращают возможные конфликты или же разрешают уже возникшие. Ни один конфликт не должен нарушать обмен, все абоненты должны, в конце концов, передать свои пакеты.
В процессе развития локальных сетей было разработано несколько разновидностей случайных методов управления обменом.
Коллизии в случае начала передачи при свободной сети
Рис. 4.10. Коллизии в случае начала передачи при свободной сети
Коллизии в случае начала передачи после освобождения сети
Рис. 4.11. Коллизии в случае начала передачи после освобождения сети
Например, был предложен метод, при котором не все передающие абоненты распознают коллизию, а только те, которые имеют меньшие приоритеты. Абонент с максимальным приоритетом из всех, начавших передачу, закончит передачу своего пакета без ошибок. Остальные, обнаружив коллизию, прекратят свою передачу и будут ждать освобождения сети для новой попытки. Для контроля коллизии каждый передающий абонент производит побитное сравнение передаваемой им в сеть информации и данных, присутствующих в сети. Побеждает тот абонент, заголовок пакета которого дольше других не искажается от коллизии. Этот метод, называемый децентрализованным кодовым приоритетным методом, отличается низким быстродействием и сложностью реализации.
При другом методе управления обменом каждый абонент начинает свою передачу после освобождения сети не сразу, а, выдержав свою, строго индивидуальную задержку, что предотвращает коллизии после освобождения сети и тем самым сводит к минимуму общее количество коллизий. Максимальным приоритетом в этом случае будет обладать абонент с минимальной задержкой. Столкновения пакетов возможны только тогда, когда два и более абонентов захотели передавать одновременно при свободной сети. Этот метод, называемый децентрализованным временным приоритетным методом, хорошо работает только в небольших сетях, так как каждому абоненту нужно обеспечить свою индивидуальную задержку.
В обоих случаях имеется система приоритетов, все же данные методы относятся к случайным, так как исход конкуренции невозможно предсказать. Случайные приоритетные методы ставят абонентов в неравные условия при большой интенсивности обмена по сети, так как высокоприоритетные абоненты могут надолго заблокировать сеть для низкоприоритетных абонентов.
[pagebreak]
Чаще всего система приоритетов в методе управления обменом в шине отсутствует полностью. Именно так работает наиболее распространенный стандартный метод управления обменом CSMA/CD (Carrier Sense Multiple Access with Collision Detection – множественный доступ с контролем несущей и обнаружением коллизий), используемый в сети Ethernet. Его главное достоинство в том, что все абоненты полностью равноправны, и ни один из них не может надолго заблокировать обмен другому (как в случае наличия приоритетов). В этом методе коллизии не предотвращаются, а разрешаются.
Суть метода состоит в том, что абонент начинает передавать сразу, как только он выяснит, что сеть свободна. Если возникают коллизии, то они обнаруживаются всеми передающими абонентами. После чего все абоненты прекращают свою передачу и возобновляют попытку начать новую передачу пакета через временной интервал, длительность которого выбирается случайным образом. Поэтому повторные коллизии маловероятны.
Еще один распространенный метод случайного доступа – CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance – множественный доступ с контролем несущей и избежанием коллизий) применяющийся, например, в сети Apple LocalTalk. Абонент, желающий передавать и обнаруживший освобождение сети, передает сначала короткий управляющий пакет запроса на передачу. Затем он заданное время ждет ответного короткого управляющего пакета подтверждения запроса от абонента-приемника. Если ответа нет, передача откладывается. Если ответ получен, передается пакет. Коллизии полностью не устраняются, но в основном сталкиваются управляющие пакеты. Столкновения информационных пакетов выявляются на более высоких уровнях протокола.
Подобные методы будут хорошо работать только при не слишком большой интенсивности обмена по сети. Считается, что приемлемое качество связи обеспечивается при нагрузке не выше 30—40% (то есть когда сеть занята передачей информации примерно на 30—40% всего времени). При большей нагрузке повторные столкновения учащаются настолько, что наступает так называемый коллапс или крах сети, представляющий собой резкое падение ее производительности.
Недостаток всех случайных методов состоит еще и в том, что они не гарантируют величину времени доступа к сети, которая зависит не только от выбора задержки между попытками передачи, но и от общей загруженности сети. Поэтому, например, в сетях, выполняющих задачи управления оборудованием (на производстве, в научных лабораториях), где требуется быстрая реакция на внешние события, сети со случайными методами управления используются довольно редко.
При любом случайном методе управления обменом, использующем детектирование коллизии (в частности, при CSMA/CD), возникает вопрос о том, какой должна быть минимальная длительность пакета, чтобы коллизию обнаружили все начавшие передавать абоненты. Ведь сигнал по любой физической среде распространяется не мгновенно, и при больших размерах сети (диаметре сети) задержка распространения может составлять десятки и сотни микросекунд. Кроме того, информацию об одновременно происходящих событиях разные абоненты получают не в одно время. С тем чтобы рассчитать минимальную длительность пакета, следует обратиться к рис. 4.12.
Пусть L – полная длина сети, V – скорость распространения сигнала в используемом кабеле. Допустим, абонент 1 закончил свою передачу, а абоненты 2 и 3 захотели передавать во время передачи абонента 1 и ждали освобождения сети.
После освобождения сети абонент 2 начнет передавать сразу же, так как он расположен рядом с абонентом 1. Абонент 3 после освобождения сети узнает об этом событии и начнет свою передачу через временной интервал прохождения сигнала по всей длине сети, то есть через время L/V. При этом пакет от абонента 3 дойдет до абонента 2 еще через временной интервал L/V после начала передачи абонентом 3 (обратный путь сигнала). К этому моменту передача пакета абонентом 2 не должна закончиться, иначе абонент 2 так и не узнает о столкновении пакетов (о коллизии), в результате чего будет передан неправильный пакет.
Получается, что минимально допустимая длительность пакета в сети должна составлять 2L/V, то есть равняться удвоенному времени распространения сигнала по полной длине сети (или по пути наибольшей длины в сети). Это время называется двойным или круговым временем задержки сигнала в сети или PDV (Path Delay Value). Этот же временной интервал можно рассматривать как универсальную меру одновременности любых событий в сети.
Стандартом на сеть задается как раз величина PDV, определяющая минимальную длину пакета, и из нее уже рассчитывается допустимая длина сети. Дело в том, что скорость распространения сигнала в сети для разных кабелей отличается. Кроме того, надо еще учитывать задержки сигнала в различных сетевых устройствах. Расчетам допустимых конфигураций сети Ethernet посвящена глава 10.
Отдельно следует остановиться на том, как сетевые адаптеры распознают коллизию в кабеле шины, то есть столкновение пакетов. Ведь простое побитное сравнение передаваемой абонентом информации с той, которая реально присутствует в сети, возможно только в случае самого простого кода NRZ, используемого довольно редко. При применении манчестерского кода, который обычно подразумевается в случае метода управления обменом CSMA/CD, требуется принципиально другой подход.
Как уже отмечалось, сигнал в манчестерском коде всегда имеет постоянную составляющую, равную половине размаха сигнала (если один из двух уровней сигнала нулевой). Однако в случае столкновения двух и более пакетов (при коллизии) это правило выполняться не будет. Постоянная составляющая суммарного сигнала в сети будет обязательно больше или меньше половины размаха (рис. 4.13). Ведь пакеты всегда отличаются друг от друга и к тому же сдвинуты друг относительно друга во времени. Именно по выходу уровня постоянной составляющей за установленные пределы и определяет каждый сетевой адаптер наличие коллизии в сети.
Определение факта коллизии в шине при использовании манчестерского кода
Рис. 4.13. Определение факта коллизии в шине при использовании манчестерского кода
Задача обнаружения коллизии существенно упрощается, если используется не истинная шина, а равноценная ей пассивная звезда (рис. 4.14).
Обнаружение коллизии в сети пассивная звезда
Рис. 4.14. Обнаружение коллизии в сети пассивная звезда
При этом каждый абонент соединяется с центральным концентратором, как правило, двумя кабелями, каждый из которых передает информацию в своем направлении. Во время передачи своего пакета абоненту достаточно всего лишь контролировать, не приходит ли ему в данный момент по встречному кабелю (приемному) другой пакет. Если встречный пакет приходит, то детектируется коллизия. Точно так же обнаруживает коллизии и концентратор.
Управление обменом в сети с топологией кольцо
Кольцевая топология имеет свои особенности при выборе метода управления обменом. В этом случае важно то, что любой пакет, посланный по кольцу, последовательно пройдя всех абонентов, через некоторое время возвратится в ту же точку, к тому же абоненту, который его передавал (так как топология замкнутая). Здесь нет одновременного распространения сигнала в две стороны, как в топологии шина. Как уже отмечалось, сети с топологией кольцо бывают однонаправленными и двунаправленными. Наиболее распространены однонаправленные.
В сети с топологией кольцо можно использовать различные централизованные методы управления (как в звезде), а также методы случайного доступа (как в шине), но чаще выбирают все-таки специфические методы управления, в наибольшей степени соответствующие особенностям кольца.
Самые популярные методы управления в кольцевых сетях маркерные (эстафетные), те, которые используют маркер (эстафету) – небольшой управляющий пакет специального вида. Именно эстафетная передача маркера по кольцу позволяет передавать право на захват сети от одного абонента к другому. Маркерные методы относятся к децентрализованным и детерминированным методам управления обменом в сети. В них нет явно выраженного центра, но существует четкая система приоритетов, и потому не бывает конфликтов.
Работа маркерного метода управления в сети с топологией кольцо представлена на рис. 4.15.
Рис. 4.15. Маркерный метод управления обменом (СМ—свободный маркер, ЗМ— занятый маркер, МП— занятый маркер с подтверждением, ПД—пакет данных)
По кольцу непрерывно ходит специальный управляющий пакет минимальной длины, маркер, предоставляющий абонентам право передавать свой пакет. Алгоритм действий абонентов:
1. Абонент 1, желающий передать свой пакет, должен дождаться прихода к нему свободного маркера. Затем он присоединяет к маркеру свой пакет, помечает маркер как занятый и отправляет эту посылку следующему по кольцу абоненту.
2. Все остальные абоненты (2, 3, 4), получив маркер с присоединенным пакетом, проверяют, им ли адресован пакет. Если пакет адресован не им, то они передают полученную посылку (маркер + пакет) дальше по кольцу.
3. Если какой-то абонент (в данном случае это абонент 2) распознает пакет как адресованный ему, то он его принимает, устанавливает в маркере бит подтверждения приема и передает посылку (маркер + пакет) дальше по кольцу.
4. Передававший абонент 1 получает свою посылку, прошедшую по всему кольцу, обратно, помечает маркер как свободный, удаляет из сети свой пакет и посылает свободный маркер дальше по кольцу. Абонент, желающий передавать, ждет этого маркера, и все повторяется снова.
Приоритет при данном методе управления получается географический, то есть право передачи после освобождения сети переходит к следующему по направлению кольца абоненту от последнего передававшего абонента. Но эта система приоритетов работает только при большой интенсивности обмена. При малой интенсивности обмена все абоненты равноправны, и время доступа к сети каждого из них определяется только положением маркера в момент возникновения заявки на передачу.
В чем-то рассматриваемый метод похож на метод опроса (централизованный), хотя явно выделенного центра здесь не существует. Однако некий центр обычно все-таки присутствует. Один из абонентов (или специальное устройство) должен следить, чтобы маркер не потерялся в процессе прохождения по кольцу (например, из-за действия помех или сбоя в работе какого-то абонента, а также из-за подключения и отключения абонентов). В противном случае механизм доступа работать не будет. Следовательно, надежность управления в данном случае снижается (выход центра из строя приводит к полной дезорганизации обмена). Существуют специальные средства для повышения надежности и восстановления центра контроля маркера.
Основное преимущество маркерного метода перед CSMA/CD состоит в гарантированной величине времени доступа. Его максимальная величина, как и при централизованном методе, составит (N-1)• tпк, где N – полное число абонентов в сети, tпк – время прохождения пакета по кольцу. Вообще, маркерный метод управления обменом при большой интенсивности обмена в сети (загруженность более 30—40%) гораздо эффективнее случайных методов. Он позволяет сети работать с большей нагрузкой, которая теоретически может даже приближаться к 100%.
Метод маркерного доступа используется не только в кольце (например, в сети IBM Token Ring или FDDI), но и в шине (в частности, сеть Arcnet-BUS), а также в пассивной звезде (к примеру, сеть Arcnet-STAR). В этих случаях реализуется не физическое, а логическое кольцо, то есть все абоненты последовательно передают друг другу маркер, и эта цепочка передачи маркеров замкнута в кольцо (рис. 4.16). При этом совмещаются достоинства физической топологии шина и маркерного метода управления.
Применение маркерного метода управления в шине
Рис. 4.16. Применение маркерного метода управления в шине
Поиск
