Что такое ключ связи в 1с

Про "ОтборСтрок" я уже писал в недалеком прошлом поэтому не буду повторяться. Что это и для чего это используется можно изучить в статье Отборы (поиск) в табличной части либо таблице значений (управляемые формы)

Для демонстрации механизма я снова подготовил небольшую конфигурацию, которую можно скачать.

Конфигурация состоит из двух справочников: "Контрагенты" и "Товары" и одного документа "Поступление товаров". Данный документ имеет 2 соответствующие табличные части и предназначен для получения товаров от разных клиентов в одном документе.

Визуально форма выглядит так:

Мы хотим сделать так, чтобы клиенту было удобно и он выбирая клиента видел только те товары, которые приходят от него.

В качестве ключа связи мы будем использовать само значение контрагента. При этом можно в качестве ключа связи использовать произвольные ключи, уникальные в пределах документа или любые ссылочные элементы, например договора контрагентов — все зависит только от вашей необходимости.

Для нашей левой табличной части "Контрагенты" нам надо добавить следующие обработчики событий:

Нам надо при активизации строки показывать только товары, принадлежащие выбранному контрагенту (События "При активизации строки" и "При окончании редактирования") и так же отработать ситуацию удаления контрагента — нам надо удалить все товары со второй табличной части.

Сами процедуры обработки:

Для правой табличной части "Товары" нам также надо обработать несколько событий:

Мы должны отклонить выбор номенклатуры если у нас нет или не выбран контрагент и автоматически заполнять значение ключа связи — в нашем случае это ссылка на контрагента. Сами процедуры:

Ну и в основном для вопросов отладки нам надо посмотреть все товары всех клиентов, для этого добавляем команду по очистке отборов и размещаем ее в интерфейсе с ограничением по правам (если требуется). Процедура простейшая:

Для того, чтобы учесть возможность смены самого контрагента, мы добавили в форме реквизит табличной части :

Сделали его заполнение при открытии формы и обрабатываем его изменение в коде:

Для большей универсальности стал использовать реквизит формы "НаименованиеКлючаСвязи", который устанавливаю 1 раз и использую потом везде.

При этом хочу обратить ваше внимание вопрос повторности контрагентов остается открытым — т.е. при выборе слева одного контрагента 2 раза система не сможет различить номенклатуру по строкам. Вам либо надо контролировать, чтобы информация слева была уникальная и/или неизменной.

Для презентации того, как можно учесть и данный случай, я добавил в конфигурацию еще один документ "ПродажаТовара", в котором в качестве ключа связи испльзуется уникальный индекс — простое число, которое уникально для каждой строки слева и привязка идет непосредственно к нему:

Основы SQL. Урок №1

Эта статья написана с целью на простых доступных примерах показать, что представляет собой SQL (Structured Query Language) – структурированный язык запросов.

База данных – это структурированный набор постоянно хранимых данных.

В реляционной базе данных информация хранится в виде двумерных таблиц.

В качестве иллюстрации базы данных 1С 8.3 рассмотрим адресную книгу. В ней содержится множество записей, соответствующих отдельным сотрудникам. Для каждого сотрудника определены данные: имя, номер телефона, адрес. Формат адресной книги – таблица со строками и столбцами. Строки соответствуют сотрудникам, а столбцы содержат имя, номер телефона и адрес.

3-я ул. Строителей

Но как быть, если есть два сотрудника с одинаковым именем? А в базе данных могут содержаться тысячи и миллионы записей.

Для решения данной задачи необходимо присвоить каждому сотруднику уникальный идентификатор. Такое значение, которое должно быть уникальным для каждого сотрудника, называется первичным ключом в базе (primary key). Каждая создаваемая таблица базы данных должна иметь первичный ключ. Он служит для логической идентификации отдельных строк. Добавим столбец для первичного ключа в нашу таблицу.

3-я ул. Строителей

Создав несколько таблиц с взаимосвязанной информацией, вы сможете выполнять над своими данными более сложные операции.

Предположим, в таблице Сотрудники требуется добавить столбец с номерами телефонов. Большинство сотрудников имеют как минимум два телефонных номера – домашний и рабочий, а ведь их может быть и больше.

Решением является построение другой таблицы, назовем ее Телефоны. Первый столбец будет содержать номер телефона, второй – описание типа номера (домашний, рабочий и т.д.). Разумеется, при этом требуется «связать» номер телефона в его владельцем (из первой таблицы) Поэтому необходимо найти способ установки связи между таблицами.

Для этого можно поместить в таблицу Телефоны первичный ключ из таблицы Сотрудники. Эти номера уникальны, поэтому можно точно определить, какому сотруднику соответствует данный номер.

Столбец id_num в таблице Телефоны называется внешним ключом (foreign key). Говорят, что он ссылается на первичный ключ таблицы Сотрудники. Ключи, на которые ссылаются внешние ключи, называются родительскими (parent) ключами. Если все значения внешнего ключа таблицы Телефоны ссылаются на значения, которые действительно присутствуют в таблице Сотрудники, то система обладает ссылочной целостностью (referential integrity).

Для таблицы Телефоны также необходим первичный ключ – его должна иметь каждая таблица. Мы не можем использовать id_num, поскольку он не является уникальным (повторяется для телефонных номеров одного сотрудника, как показано в таблице для сотрудника 1008 по имени Васина).

Первичный или внешний ключ необязательно должен состоять из одного столбца. Можно скомбинировать столбцы id_num и phone. Такая комбинация будет уникальной. Итак, комбинация id_numи phone является логическим первичным ключом для таблицы Телефоны. Ключ, состоящий более чем из одного столбца, в разных СУБД называется составным (composite).

2. Соединение двух таблиц

Теперь нужно связать вторую таблицу с первой так, чтобы номерам телефонов соответствовала информация о клиентах. Наличие в одной из таблиц внешнего ключа, значения которого совпадают со значениями первичного ключа другой таблицы, является достаточным условием для определения того, какие строки таблиц связаны (относятся к одному сотруднику). При этом обязательно тип данных внешнего ключа исходной таблицы должен совпадать с типом данных первичного ключа таблицы, с которой происходит соединение при соединении двух таблиц.

Операция извлечения информации из базы данных называется запросом (query).

В 70-х годах XX века, был создан специальный язык SEQUEL, позволявший относительно просто управлять данными в этой СУБД. Аббревиатура SEQUEL расшифровывалась как Structured English QUEry Language — «структурированный английский язык запросов».

Целью разработки было создание простого непроцедурного языка, позволяющего любому пользователю, даже не имеющему навыков программирования, извлекать данные из базы.

Позже он был переименован в SQL – Structured Query Language – структурированный язык запросов. Позднее, с принятием стандартов, SQL превратился в самостоятельный язык, применяемый в разработке баз данных.

В основном SQL-запросы реализуются с помощью оператора SEL ECT. Запрос, извлекающий данные из более чем одной таблицы путем сопоставления столбцов одной таблицы столбцам других таблиц, называется соединением (join).

В общем виде синтаксис минимальной команды такой:

SELECT имена полей таблиц FROM имена таблиц

В 1С обычно пишут запросы 1С 8.3 в русскоязычном синтаксисе :

ВЫБРАТЬ имена полей таблиц ИЗ имена таблиц

Таким образом в результате мы получаем таблицу, но уже состоящую из тех строк и столбцов исходных таблиц, которые нам необходимы. Группа взаимосвязанных таблиц называется схемой (schema).

3. Несколько простых примеров в системе 1С:Предприятие

Система 1С:Предприятие. Создадим справочники Сотрудники и Города. Заполним их данными.

Главная и подчиненная таблицы в 1С — связывание

Наверняка многие сталкивались с вопросом о связывании двух- и более таблиц на формах 1С по принципу главная-подчиненная. Один из возможных вариантов решения я приведу в этой статье. Некоторые решения я уже встречал, но они либо ограничивают возможности таблиц (невозможность сортировки, изменения номера строки и перестановки строк местами) либо требовали дополнительного кода по обработке различных изменений в связанной информации. Предлагаю более разумное и довольно простое решение.

Идея:

1. Необходима уникальная скрытая связка в двух таблицах, обеспечивающая простую в обработке синхронизацию полей главной и подчиненной таблиц.

Реализация:

В поисках такой универсальной связки наткнулся на конструкцию вида:

Как раз его и будем использовать для связывания. В обе табличные части документа добавляем поле с типом УникальныйИдентификатор. После этого необходимо в модуле формы обработать несколько событий, а именно:

ПриНачалеРедактирования — Табличного поля главной таблицы и Табличного поля подчиненной таблицы.

ПередУдалением — Табличного поля главной таблицы для очистки связанных строк подчиненной.

ПриАктивизацииСтроки — для отбора строк подчиненной таблицы.

А теперь примеры обработчиков, кстати, они универсальны для любых решений.

И совсем небольшое дополнение — полю ИД устанавливаем Свойство:Индексировать = индексировать.

Поле Табличного Поля можно (и нужно во избежание) сделать недоступным для пользователя.

1.3. Типы связей и ключей в рбд

Как уже отмечалось, в БД все таблицы должны быть так или иначе связаны между собой, чтобы обеспечить целостность данных, создающих информационную модель некой предметной области. Если оказалось, что одна из таблиц в создаваемой БД не имеет связей ни с одной другой таблицей, то в этом случае необходимо создавать новую БД либо рассматривать более широкую предметную область, для которой создается БД.

Связи между таблицами организуются с помощью различных ключей. Связное отношение хранит ключи двух или более объектных отношений, по этим ключам устанавливаются связи между объектами. Связное отношение кроме связываемых ключей может иметь и другие атрибуты, которые будут функционально зависеть от этой связи. Ключи в связных отношениях называются внешними ключами, поскольку они являются первичными ключами других отношений.

Каждому внешнему ключу должна соответствовать строка какого-либо объектного отношения. Невыполнение этого ограничения может привести к нарушению ссылочной целостности данных. Ключ должен ссылаться на объект, который существует.

Перечислим условия и ограничения, накладываемые на отношения реляционной моделью данных, которые позволяют таблицы считать отношениями:

1. Не может быть одинаковых значений для первичных ключей, т.е. все строки таблицы должны быть в целом уникальны и определяться значением первичного ключа однозначно.

2. Все строки таблицы должны иметь одну и ту же структуру, т.е. одно и то же количество атрибутов.

3. Имена столбцов таблицы должны быть различны, а значения столбцов должны быть однотипными.

4. Значения атрибутов должны быть простыми, следовательно, отношения не могут иметь в качестве компонент другие отношения.

5. Должна соблюдаться ссылочная целостность для внешних ключей.

6. Порядок следования строк в таблице несущественен — он лишь влияет на скорость доступа к строке.

Хорошо организованная база данных обеспечивает удобный доступ к хранящейся в ней информации. При правильном проектировании базы данных будет меньше затрачиваться времени и усилий на ввод данных в базу, внесение изменений и извлечение данных из базы.

Этап установки связей между таблицами нужен для того, чтобы указать, какие действия надо предпринимать для объединения содержимого таблиц, составляющих РБД. После того как пользователь установит связи между таблицами, СУБД сможет использовать эти связи для поиска связанной информации в разных таблицах базы данных.

В теории РБД существует три типа межтабличных отношений или связей: один-ко-многим, многие-ко-многим и один-к-одному (четвертый возможный тип отношений — многие-к-одному фактически сводится к первому типу, так как является его «зеркальным отражением» и в СУБД Access просто совпадает со связью один-ко-многим).

Связь один-ко-многим является наиболее распространенной в реляционных базах данных. При таком типе отношений одной записи в первой таблице могут соответствовать несколько записей во второй таблице, однако каждой записи во второй таблице соответствует не более одной записи в первой таблице, что отражает в полной мере функциональную зависимость второй таблицы от первой.

Связь многие-ко-многим означает, что каждой записи в первой таблице могут соответствовать несколько записей во второй таблице, а каждой записи во второй таблице — несколько записей в первой таблице. В СУБД Access такой тип отношений напрямую не допускается, и во избежание такой ситуации создается еще одна вспомогательная таблица, которая связывается с обеими исходными таблицами связью типа один-ко-многим.

При связи один-к-одному каждой записи в первой таблице может соответствовать не более одной записи во второй таблице, а каждой записи во второй таблице — не более одной записи в первой таблице. Такой тип межтабличных отношений используется тогда, когда для удобства в работе очень широкую таблицу разбивают на две с повторением одного поля в каждой либо когда из таблицы необходимо выделить часть, к которой нужно обеспечить особый режим допуска (например, конфиденциальные сведения о сотрудниках, содержащиеся в одном или нескольких полях таблицы, к которым должны иметь доступ только определенные лица).

Читать:

Как открыть файл cvs в excel

В любом случае наличие связей (отношений) между таблицами второго и третьего типов означает, что база данных спроектирована не совсем оптимально или же просто содержит ошибки. Хорошо спроектированная база данных обычно не содержит отношений между таблицами двух последних типов.

Как уже отмечалось выше, основным достоинством любой БД является способность быстро находить и объединять информацию, хранящуюся в разных таблицах. Для решения первой задачи каждая таблица в БД должна содержать поле или набор полей, значение которого или совокупность значений которых однозначно определяет каждую запись этой таблицы. На языке БД такое поле или совокупность полей называется ключом таблицы, а точнее, первичным ключом таблицы. При этом кандидатами на роль ключа таблицы могут быть любые поля, которые содержат уникальные (неповторяющиеся) значения для каждой записи, т.н. потенциальные ключи таблицы. Если в роли ключа выступают сразу несколько полей, когда в таблице просто нет одного поля с неповторяющимися значениями, то приходится подбирать такую комбинацию полей, значение которой будет уникальным. Такой ключ называется составным ключом.

Для решения второй из названных задач — объединения информации и организации связей между таблицами — используются поля таблиц, имеющие совпадающие значения. При этом связь один-ко-многим образуется между первичным ключом одной таблицы, которая называется главной, и т.н. внешним, или вторичным, ключом другой таблицы, которая называется подчиненной. Значения внешнего ключа в таблице могут повторяться (отсюда термин ко-многим в названии связи), а сам внешний ключ, например поле «Поставщик» в таблице «Товары» или поле «Индекс» в таблице «Поставщики», получил такое название потому, что при проектировании (разложении) таблицы на составляющие такое поле специально вводится в вычленяемую таблицу именно для организации связей между таблицами и обеспечения целостности данных в БД.

Таким образом, в нашей БД «Поставки товаров», состоящей из таблиц «Товары», «Поставщики» и «Адреса», необходимо организовать следующие межтабличные связи (ниже мы используем схематичное изображение межтабличных связей, совпадающее с представлением схемы связей в СУБД Access, работа в которой будет рассматриваться в последующих разделах пособия, здесь символ  соответствует термину ко-многим):

Записки IT специалиста

Ключи защиты 1С Предприятие 8.1. Особенности использования.

Автор: Уваров А.С.
10.02.2010

Действия многих системных администраторов, столкнувшихся со сложностями при установке ключей защиты для 1С Предприятия, более всего напоминают шаманские камлания с бубном. В «админских кругах», да и в интернете, ходят мифы и легенды о «капризности» ключей защиты, о ее «кривой» реализации и т.п. В тоже время большинство нестандартных ситуаций является следствием крайне низкого уровня знаний о ключах защиты и особенностях их использования.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Какие бывают ключи

Локальные однопользовательские ключи представлены моделью HASP HL Basic (синего цвета), данный ключ имеет маркировку H4 M1 ORGL8, не имеет встроенной памяти и персонального ID, не хранит в себе никаких параметров и настроек. Поставляется продуктами имеющими лицензию на одно рабочее место.

Сетевые клиентские ключи включают серию HASP HL Net (красного цвета). Имеют внутреннюю память, в которой хранится количество лицензий, и уникальный ID. Существуют разновидности на 5, 10, 20, 50 и 100 пользователей. Имеет маркировку NETXX ORGL8, где ХX — количество лицензий (например NET5 ORGL8). Существуют также ключи на 300 и 500 пользователей которые имеют маркировку NET250+ ORG8A и NET250+ ORG8B. Поставляются с продуктами имеющими лицензию на 5 рабочих мест, а также отдельно, в виде дополнительных клиентских лицензий.

Ключи для сервера 1С Предприятие бывают только локальные. 32-битная версия имеет ключ защиты HASP HL Pro (фиолетового цвета), который имеет внутреннюю память и уникальный ID. Имеет маркировку ENSR8, поставляется вместе с лицензией на сервер 1С Предприятие.

Для 64-битного сервера используется ключ HASP HL Max (зеленого цвета) с внутренней памятью и уникальным ID. Имеет маркировку EN8SAи поддерживает также 32-битный сервер. Т.е. имея лицензию на 64-битный сервер можно, не меняя ключа, использовать 32-битную версию, но не наоборот.

Как правильно устанавливать ключи

Следует запомнить одно важное правило: на один компьютер нельзя устанавливать более одного ключа одной серии. Также не рекомендуется ставить вместе локальный и сетевой ключ, это связано с особенностью защиты 1С Предприятия: находя локальный ключ программа никогда не будет искать сетевой. Локальные ключи сервера 1С Предприятия не мешают работе других ключей.

Второе важное правило: ключ не должен находится на машине с активным терминальным ПО . Также не стоит ставить менеджер лицензий в терминале. 1С на сервере терминалов может работать только с сетевым ключом, расположенным на другом ПК.

При наличии двух и более сетевых ключей недостаточно разнести их по разным компьютерам. Следует выполнить настройку менеджеров лицензий. Каждый менеджер лицензий должен иметь уникальное имя, которое следует явным образом сообщить защищаемой программе. Рекомендуется выполнить аналогичную настройку и в случае использования сервера терминалов, даже при одном сетевом ключе.

На машине где установлен ключ находим файл nhsrv.ini в папке с менеджером лицензий. За имя сервера лицензий отвечает параметр NHS_SERVERNAMES, оно может состоять из латинских букв и цифр и содержать не более 7 символов.

После чего на клиентских машинах следует отредактировать файл nethasp.ini , явным образом указав адреса и имена менеджеров лицензий:

Какие бывают ошибки

К сожалению 1С Предприятие вместо штатных сообщения HASP об ошибках выводит собственное «Не обнаружен ключ защиты программы!» . Под этим сообщением может скрываться четыре вида ошибок, рассмотрим их подробнее.

Не найден ключ. Пожалуй самая распространенная ошибка. Возникает при отсутствии ключа, попытке использования ключа от другого продукта. Для сетевых ключей эта ошибка может возникать при отсутствии сети, если на машине с ключом не запущен менеджер лицензий, закрыт 457 порт или ошибочно установлен несетевой ключ.
Ключ не содержит лицензии. Возникает при установке на один ПК двух ключей одной серии, при этом виден тот из них, на котором отсутствует нужная лицензия. При работе в сети двух менеджеров лицензий с одинаковыми именами и обслуживающими ключи одной серии приложение может найти первым ключ не содержащий нужной лицензии, что также приведет к получению этой ошибки.
Обнаружена служба терминалов. Возникает при попытке запустить приложение из терминальной сессии с локальным ключом. Может также возникнуть в случае если в nethasp.ini явно не прописан адрес менеджера лицензий.
Превышено число лицензий. Возникает когда количество пользователей (активных сессий) превышает число указанных в ключе лицензий. При работе в сети двух менеджеров лицензий с одинаковыми именами и обслуживающими ключи одной серии приложение может найти первым ключ с которым уже установлено максимальное количество соединений, что также приведет к получению этой ошибки.

Дополнительные материалы: