Как поменять владельца базы sql 1с
Предоставление пользователю доступа к базе данных включает три шага. Вначале создается имя входа. Имя входа дает пользователю возможность подключиться к компоненту Компонент SQL Server Database Engine. Затем имя входа настраивается как пользователь в заданной базе данных. Наконец, предоставляются пользовательские разрешения на объекты базы данных. В этом занятии показаны все три шага, а также создание представления и хранимой процедуры в виде объекта.
В этом занятии используются объекты, созданные в разделе Урок 1. Создание объектов баз данных. Пройдите урок 1, прежде чем переходить к уроку 2.
Предварительные требования
Для работы с этим руководством необходима среда SQL Server Management Studio и доступ к экземпляру SQL Server.
Если у вас нет доступа к экземпляру SQL Server, выберите свою платформу в следующих ссылках. При выборе проверки подлинности SQL используйте учетные данные SQL Server.
- Windows: скачать выпуск SQL Server 2017 Developer Edition.
- macOS: скачать SQL Server 2017 для Docker.
Мы слушаем! Если вы обнаружили в этой статье устаревшие или недостоверные сведения, например инструкции или пример кода, сообщите нам. Можно воспользоваться кнопкой Эта страница в разделе Отзывы внизу страницы. Обычно мы читаем отзывы про материалы по SQL на следующий день. Благодарим вас.
Создает вход
Чтобы получить доступ к компоненту Компонент Database Engine, необходимо иметь имя входа. Имя входа может идентифицировать пользователя как учетную запись Windows или как члена группы Windows, или имя входа может быть именем входа SQL Server , которое существует только в SQL Server. При возможности используйте проверку подлинности Windows.
По умолчанию администраторы компьютера имеют полный доступ к SQL Server. Для этого занятия нужно иметь пользователя с меньшим правом доступа; следовательно, вы создадите новую локальную учетную запись проверки подлинности Windows на компьютере. Чтобы сделать это, нужно быть администратором на своем компьютере. После этого нужно предоставить новому пользователю доступ к SQL Server.
Создание учетной записи Windows
Создание имени для входа SQL
В окне редактора запросов среды SQL Server Management Studioвведите и выполните следующий исходный код, заменив computer_name на имя компьютера. FROM WINDOWS указывает, что Windows проверит подлинность пользователя. Необязательный аргумент DEFAULT_DATABASE соединяет Mary с базой данных TestData , если только в ее строке соединения не указана другая база данных. Эта инструкция рассматривает точку с запятой в виде необязательного завершения инструкции языка Transact-SQL .
Этим авторизируется имя пользователя Mary , проверенное компьютером, чтобы получить доступ к экземпляру SQL Server. Если на компьютере находится более одного экземпляра SQL Server , нужно создать имя входа для каждого экземпляра, к которому Mary должна иметь доступ.
Поскольку Mary не является доменной учетной записью, это имя пользователя может быть принято только на данном компьютере.
Предоставление доступа к базе данных
Теперь Mary имеет доступ к данному экземпляру SQL Server, но не имеет разрешения на доступ к базе данных. У нее даже нет доступа к своей базе данных по умолчанию TestData , пока вы не авторизируете ее в качестве пользователя базы данных.
Чтобы предоставить Mary доступ, переключитесь на базу данных TestData и при помощи инструкции CREATE USER сопоставьте ее имя входа с именем пользователя «Mary».
Создание пользователя в базе данных
Введите и выполните следующие инструкции (заменяя computer_name на имя компьютера), чтобы предоставить пользователю Mary доступ к базе данных TestData .
Теперь пользователь Mary имеет доступ к SQL Server и к базе данных TestData .
Создание представлений и хранимых процедур
Будучи администратором, можно выполнять инструкцию SELECT из таблицы Products и представления vw_Names, а также выполнять процедуру pr_Names; однако Мэри всего этого не может. Чтобы предоставить Mary необходимые разрешения, воспользуйтесь инструкцией GRANT.
Предоставление разрешений на хранимые процедуры
Выполните следующую инструкцию, чтобы предоставить Mary разрешение на EXECUTE для хранимой процедуры pr_Names .
В данном сценарии Mary имеет доступ только к таблице Products посредством хранимой процедуры. Если Mary нужно выполнять инструкцию SELECT к представлению, нужно выполнить инструкцию GRANT SELECT ON vw_Names TO Mary . Чтобы удалить доступ к объектам базы данных, воспользуйтесь инструкцией REVOKE.
Если таблицей, представлением или хранимой процедурой не владеет та же схема, процесс предоставления прав становится более сложным.
Об инструкции GRANT
Нужно иметь разрешение на EXECUTE, чтобы выполнить хранимую процедуру. Нужно иметь разрешения на SELECT, INSERT, UPDATE и DELETE, чтобы получить доступ к данным и изменять их. Инструкция GRANT также используется для других разрешений, например для разрешений на создание таблиц.
Дальнейшие действия
В следующей статье вы узнаете, как удалить объекты базы данных, созданные в других уроках.
При развертывании информационных баз предприятий на основе решений 1С в клиент-серверном режиме с использованием СУБД MS SQL иногда бывает нужно, чтобы разные базы создавались от имени разных пользователей. Т.е. нам бывает нужно завести в SQL Management Studio пользователя, отличного от sa и ввести его данные в поля окна добавления новой ИБ. (рис1.)
Каковы минимальные права, при которых это всё будет функционировать?
В материалах методической поддержки ИТС говорится, что «этот пользователь должен иметь не только полные права на базу данных информационной базы, но и права на создание баз данных в SQL-сервере и на чтение таблиц базы данных Master». Чтобы посмотреть, как это работает на практике, проведем тестовую установку ИБ в клиент-серверном варианте, используя MS SQL Server 2008 R2 Express. Можно, конечно же, тупо скопировать параметры пользователя sa, но давайте сделаем это осмысленно, это всегда полезно.
Запустим среду SQL Management Studio 2008 R2, установим соединение с SQL-сервером и откроем раздел Безопасность->Имена входа и выберем команду контекстного меню «Создать имя входа», зададим имя пользователя и установим права dbcreator, public (рис.2)
На странице свойств пользователя «Сопоставление пользователей» отметим флажком «Схема» все базы в таблице сопоставленных пользователей master, model, msdb, tempdb, и для каждой базы из таблицы отметим членство в ролях public, db_owner (рис.3)
Теперь можно вернуться к окну, изображенному на рис. 1 и применить введенные параметры. Нажимаем Далее->Готово и. база создана, список баз увеличился на одну позицию.
Таким образом, мы сможем обрадовать и успокоить системного администратора, ведь указанная комбинация прав пользователя MS SQL минимально достаточна для использования с платформой 1С в клиент-серверном режиме, и пароль «sa» останется не скомпрометированным, а у нас есть нужные нам права пользователя MS SQL.
В будущей версии Microsoft SQL Server этот компонент будет удален. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется. Вместо этого используйте инструкцию ALTER AUTHORIZATION .
Синтаксис
Аргументы
[ @loginame =] "Login"
Идентификатор имени входа нового владельца текущей базы данных. Аргумент Login имеет тип sysname и не имеет значения по умолчанию. имя для входа должно быть уже существующим SQL Server именем входа или пользователем Windows. имя входа не может стать владельцем текущей базы данных, если у нее уже есть доступ к базе данных через существующую учетную запись безопасности пользователя в базе данных. Чтобы избежать этой ситуации, сначала удалите данного пользователя в текущей базе данных.
[ @map =] remap_alias_flag
Параметр remap_alias_flag является устаревшим, так как псевдонимы для входа были удалены из SQL Server . Использование параметра remap_alias_flag не приводит к ошибке, но не оказывает никакого влияния.
Значения кода возврата
0 (успешное завершение) или 1 (неуспешное завершение)
Замечания
После выполнения процедуры sp_changedbowner новый владелец становится известным в базе данных как пользователь dbo. Пользователь dbo имеет неявные разрешения на выполнение любых действий в базе данных.
Владельца системных баз данных master, model или tempdb нельзя изменить.
Чтобы отобразить список допустимых значений для входа , выполните хранимую процедуру sp_helplogins.
При запуске sp_changedbowner только с параметром Login владелец базы данных изменяется на имя для входа.
Можно изменить владельца любого защищаемого объекта с помощью инструкции ALTER AUTHORIZATION. Дополнительные сведения см. в разделе ALTER AUTHORIZATION (Transact-SQL).
Разрешения
Необходимо разрешение TAKE OWNERSHIP для базы данных. Если новый владелец имеет соответствующего пользователя в базе данных, требуется разрешение IMPERSONATE для имени входа, в противном случае необходимо разрешение CONTROL SERVER для сервера.
Примеры
В следующем примере показано, как сделать имя входа Albert владельцем текущей базы данных.
Этот синтаксис не поддерживается бессерверным пулом SQL в Azure Synapse Analytics.
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Аргументы
Защищаемый класс сущности, для которой изменяется владелец. По умолчанию это класс OBJECT.
Class | Продукт |
---|---|
OBJECT | Область применения: SQL Server 2008 и более поздние версии, База данных SQL Azure, Azure Synapse Analytics, Система платформы аналитики (PDW). |
ASSEMBLY | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
ASYMMETRIC KEY | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
AVAILABILITY GROUP | Область применения: SQL Server 2012 и выше. |
CERTIFICATE | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
CONTRACT | Применимо к: SQL Server 2008 и выше. |
DATABASE | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. Дополнительные сведения см. в статье об ALTER AUTHORIZATION для баз данных. |
ENDPOINT | Применимо к: SQL Server 2008 и выше. |
FULLTEXT CATALOG | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
FULLTEXT STOPLIST | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
MESSAGE TYPE | Применимо к: SQL Server 2008 и выше. |
REMOTE SERVICE BINDING | Применимо к: SQL Server 2008 и выше. |
ROLE | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
ROUTE | Применимо к: SQL Server 2008 и выше. |
SCHEMA | Область применения: SQL Server 2008 и более поздние версии, База данных SQL Azure, Azure Synapse Analytics, Система платформы аналитики (PDW). |
SEARCH PROPERTY LIST | Применимо к: SQL Server 2012 (11.x) и выше, База данных SQL Azure. |
SERVER ROLE | Применимо к: SQL Server 2008 и выше. |
SERVICE | Применимо к: SQL Server 2008 и выше. |
SYMMETRIC KEY | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
TYPE | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
XML SCHEMA COLLECTION | Применимо к: SQL Server 2008 и выше, База данных SQL Azure. |
entity_name — имя сущности.
principal_name | SCHEMA OWNER —имя субъекта безопасности, который будет являться владельцем сущности. Объекты базы данных должны принадлежать субъекту базы данных; пользователю базы данных или роли. Объекты сервера (такие как базы данных) должны принадлежать субъекту сервера (имя для входа). Определите SCHEMA OWNER в качестве *principal_name-, чтобы показать, что объект должен принадлежать участнику, который владеет схемой объекта.
Remarks
Инструкция ALTER AUTHORIZATION может использоваться для изменения владельца любой сущности, у которой он есть. Владение содержащимися в базе данных сущностями можно передать любому участнику уровня базы данных. Владение сущностями уровня сервера можно передать только участникам уровня сервера.
Начиная с SQL Server 2005 (9.x), пользователь может владеть объектом (OBJECT) или типом (TYPE), содержащимся в схеме, которая принадлежит другому пользователю базы данных. Это поведение было изменено по сравнению с предыдущими версиями SQL Server. Дополнительные сведения см. в разделах OBJECTPROPERTY (Transact-SQL) и TYPEPROPERTY (Transact-SQL).
Владение можно передавать для следующих, содержащихся в схемах сущностей типа «объект»: таблиц, представлений, функций, процедур, очередей и синонимов.
Нельзя передавать владение для следующих сущностей: связанных серверов, статистики, ограничений, правил, значений по умолчанию, триггеров, очередей компонента Компонент Service Broker, учетных данных, функций секционирования, схем секционирования, главных ключей баз данных, главного ключа службы, а также для уведомлений о событиях.
Нельзя передавать владение элементами следующих защищаемых классов: сервером, именем входа, пользователем, ролью приложения и столбцом.
Аргумент SCHEMA OWNER допустим только в случае передачи владения сущностью, содержащейся в схеме. Аргумент SCHEMA OWNER позволяет передать владение сущностью владельцу схемы, в которой она находится. В схемах содержатся только сущности классов OBJECT, TYPE или XML SCHEMA COLLECTION.
Если целевая сущность не представляет собой базу данных, а передаваемая сущность передается новому владельцу, все разрешения на целевую сущность удаляются.
В SQL Server 2005 (9.x) поведение схем отличается от более ранних версий SQL Server. Код, предполагающий, что схемы эквивалентны пользователям базы данных, может возвращать неверные результаты. Старые представления каталога, содержащие таблицу sysobjects, не могут быть использованы в базе данных, в которой когда-либо выполнялась любая из следующих инструкций DDL: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. В базе данных, в которой когда-либо выполнялась любая из этих инструкций, необходимо использовать новые представления каталога. В новых представлениях каталогов учитывается разделение участников и схем, введенное в SQL Server 2005 (9.x). Дополнительные сведения о представлениях каталогов см. в разделе Представления каталогов (Transact-SQL).
Имейте в виду следующее:
Единственный надежный способ найти владельца объекта — запросить представление каталога sys.objects. Единственный надежный способ найти владельца типа — использовать функцию TYPEPROPERTY.
Особые случаи и условия
В следующей таблице перечислены особые случаи, исключения и условия, касающиеся изменения авторизации.
Class | Условие |
---|---|
OBJECT | Нельзя изменить владельца триггеров, ограничений, правил, значений по умолчанию, статистик, системных объектов, очередей, индексированных представлений и таблиц с индексированными представлениями. |
SCHEMA | При передаче владения разрешения на содержащиеся в схеме объекты, у которых нет явных владельцев, удаляются. Нельзя изменить владельца схем sys, dbo и information_schema. |
TYPE | Нельзя изменить владельца сущности TYPE, принадлежащей схеме sys или information_schema. |
CONTRACT, MESSAGE TYPE или SERVICE | Нельзя изменить владельца системных сущностей. |
SYMMETRIC KEY | Нельзя изменить владельца глобальных временных ключей. |
CERTIFICATE или ASYMMETRIC KEY | Нельзя передавать владение данными сущностями роли или группе. |
ENDPOINT | Участник должен представлять собой имя входа в систему. |
ALTER AUTHORIZATION для баз данных
Для SQL Server
Требования к новому владельцу: Новый участник-владелец должен быть одним из следующих:
- имя входа для проверки подлинности SQL Server;
- имя входа для проверки подлинности Windows, представляющее пользователя Windows (а не группу);
- пользователь Windows, проходящий проверку подлинности с использованием имени входа для проверки подлинности Windows, представляющего группу Windows.
Требования к пользователю, выполняющему инструкцию ALTER AUTHORIZATION Если вы не являетесь членом предопределенной роли сервера sysadmin, вам требуется как минимум разрешение TAKE OWNERSHIP для базы данных и разрешение IMPERSONATE для имени входа нового владельца.
Для Базы данных SQL Azure
Требования к новому владельцу: Новый участник-владелец должен быть одним из следующих:
- имя входа для проверки подлинности SQL Server;
- федеративный пользователь (не группа) в Azure AD;
- управляемый пользователь (не группа) или приложение в Azure AD.
Если новый владелец является пользователем Azure Active Directory, он не может существовать как пользователь в базе данных, где новый владелец станет новым DBO. Такого пользователя Azure AD необходимо удалить из базы данных перед выполнением инструкции ALTER AUTHORIZATION, указав в качестве владельца базы данных нового пользователя. Дополнительные сведения о настройке пользователей Azure Active Directory с базой данных SQL см. в статье Подключение к базе данных SQL или Azure Synapse Analytics с использованием проверки подлинности Azure Active Directory.
Требования к пользователю, выполняющему инструкцию ALTER AUTHORIZATION Необходимо подключиться к целевой базе данных, чтобы изменить ее владельца.
Изменить владельца базы данных могут следующие типы учетных записей.
- Имя входа участника уровня службы. (Администратор SQL Azure, подготовленный при создании сервера Базы данных SQL.)
- Администратор Active Directory для Azure SQL Server.
- Текущий владелец базы данных.
Следующая таблица содержит сводку требований.
Исполнитель | Назначение | Результат |
---|---|---|
Имя входа для проверки подлинности SQL Server | Имя входа для проверки подлинности SQL Server | Успешно |
Имя входа для проверки подлинности SQL Server | Пользователь Azure AD | Ошибка |
Пользователь Azure AD | Имя входа для проверки подлинности SQL Server | Успешно |
Пользователь Azure AD | Пользователь Azure AD | Успешно |
Чтобы проверить владельца базы данных Azure AD, выполните следующую команду Transact-SQL в базе данных пользователя (в этом примере testdb ).
Рекомендации
Не используйте пользователей Azure AD в качестве отдельных владельцев базы данных — используйте группу Azure AD как член предопределенной роли базы данных db_owner. Далее приводятся действия по настройке имени входа в качестве владельца базы данных и назначению группы Azure Active Directory ( mydbogroup ) в качестве члена роли db_owner.
Войдите в SQL Server как администратор Azure AD и измените владельца базы данных на отключенное имя входа для проверки подлинности SQL Server. Например, в базе данных пользователя выполните следующую команду:
Создайте группу Azure AD, которая должна быть владельцем базы данных, и добавьте ее в качестве пользователя в базу данных пользователя. Пример:
В базе данных добавьте пользователя, представляющего группу Azure AD, в предопределенную роль базы данных db_owner. Пример:
Теперь члены mydbogroup могут централизованно управлять базой данных как члены роли db_owner.
- Когда члены этой группы удаляются из группы Azure AD, они автоматически теряют разрешения dbo на эту базу данных.
- Аналогичным образом новые члены, добавляемые в группу Azure AD mydbogroup , автоматически получают доступ dbo для этой базы данных.
Чтобы проверить наличие действующего разрешения dbo у конкретного пользователя, пользователь должен выполнить следующую инструкцию:
Возвращаемое значение 1 указывает, что пользователь является членом роли.
Разрешения
Требует разрешения TAKE OWNERSHIP для сущности. Если новый владелец не является пользователем, выполняющим данную инструкцию, также требуется одно из следующих условий: 1) разрешение IMPERSONATE для нового владельца, если это пользователь или имя входа; 2) если новый владелец представляет собой роль — членство в роли или разрешение ALTER для этой роли; 3) если новый владелец представляет собой роль приложения — разрешение ALTER для роли приложения.
Примеры
A. Передача владения таблицей
В следующем примере владение таблицей Sprockets передается пользователю MichikoOsada . Эта таблица расположена в схеме Parts .
Запрос также может выглядеть следующим образом:
Если объекты схемы не включены в инструкцию, Компонент Database Engine выполнит поиск объекта в схеме пользователей по умолчанию. Пример:
Б. Передача владения представлением владельцу схемы
В следующем примере передается владение представлением ProductionView06 владельцу содержащей его схемы. Это представление расположено в схеме Production .
В. Передача владения схемой пользователю
В следующем примере владение схемой SeattleProduction11 передается пользователю SandraAlayo .
Г. Передача владения конечной точкой имени входа в SQL Server
В следующем примере владение конечной точкой CantabSalesServer1 передается JaePak . Так как конечная точка представляет собой защищаемую сущность уровня сервера, ее можно передать только участнику уровня сервера.
Область применения: SQL Server 2008 и более поздних версий.
Д. Изменение владельца таблицы
В каждом из следующих примеров показано изменение владельца таблицы Sprockets в базе данных Parts на пользователя базы данных MichikoOsada .
Е. Изменение владельца базы данных
Применимо к: SQL Server 2008 и выше, Система платформы аналитики (PDW), База данных SQL.
В следующем примере показано, как изменить владельца базы данных Parts на имя входа MichikoOsada .
Ж. Изменение владельца базы данных SQL на пользователя Azure AD
Итак, SQL сервер запущен. Теперь самое время создать базу данных, с которой будет работать программа 1С. Несмотря на всю простоту этой процедуры, в ней есть несколько особенностей, о которых Вам следует знать.
Запустите программу "Enterprise Manager". Поставьте курсор на название сервера и из контекстного меню выберите пункт "Свойства". Перейдите на закладку "Security":
Материал, изложенный в этой главе, описан для случая авторизации "SQL Server and Windows".
О том, как в 1С настраивается подключение к SQL серверу, я расскажу позже.
Кто владелец базы данных?
Когда Вы будете создавать новую базу, ее владельцем станет та учетная запись, от имени которой Вы подключились к SQL серверу.
Чтобы посмотреть настройки подключения, поставьте курсор на название сервера и из контекстного меню выберите пункт "Edit SQL Server Registration properties …":
Раздел "Connection" определяет, каким образом Вы будете подключаться к SQL серверу из программы "Enterprise Manager". Способ подключения в конечном итоге определяет, кто станет владельцем создаваемой базы данных.
Определить владельца существующей базы очень легко - просто посмотрите ее свойства. По приведенному ниже рисунку видно, что владелец базы pubs - учетная запись sa.
Если же Вы авторизовались средствами Windows и создали новую базу, то информация о ее владельце будет выглядеть немного иначе:
Есть уточнение - доступ от имени sa разрешен, даже если владелец базы данных не sa.
Предвижу Ваше желание подключать 1С к SQL серверу от имени учетной записи sa. Это не самая лучшая идея, т.к. у этой учетной записи полные права на управление SQL сервером. Для работы 1С лучше завести отдельную учетную запись с ограниченными правами. Назовем ее Login1C.
Управление учетными записями производится в ветке "Security":
Создайте новую учетную запись с именем Login1C. На закладках "Server Roles" и "Database Access" не проставляйте никаких галочек:
Следующий шаг - сделать учетную запись Login1C владельцем базы данных. Эту операцию надо выполнять, когда база данных уже создана. Поскольку на данном этапе мы еще не создали свою базу, я расскажу, как это сделать на примере базы pubs.
Запустите программу "Query analyzer". В выпадающем списке баз данных выберите базу pubs. В окне запросов наберите команду
sp_changedbowner 'Login1c' Выполните ее. Вы должны получить следующий результат:
Владелец базы изменится на Login1C:
Точно такую же операцию Вы должны сделать, когда создадите свою базу данных, предназначенную для работы с 1С.
Создаем свою базу
Новая база создается в ветке "Databases":
В поле "Name" введите имя Вашей базы, например, Base1C. В поле "Collation name" оставьте значение по умолчанию - " (Server default)":
Перейдите на закладку "Data Files". Здесь Вам следует проверить, где SQL сервер предлагает расположить файл данных. Изначально в поле "Location" должен быть выбран путь, который во время установки мы указали SQL серверу в качестве папки для файлов данных. Если Ваши жесткие диски разбиты согласно таблице из главы "SQL сервер для 1С: установка операционной системы", то файл данных должен находиться на диске F:
Следует заострить внимание на параметре "Initial size". В этом поле указывается размер создаваемого файла данных в мегабайтах.
Если Вы только собираетесь начинать учет в программе 1С, то имеет смысл установить небольшое значение этого параметра, например, 100 Мб. Если же Вы переносите на платформу SQL существующую базу 1С размером, скажем, 1,5 Гб, то укажите в этом поле значение 1500 Мб. Поступив подобным образом, Вы выиграете в скорости загрузки данных в базу SQL, ведь файлу данных не придется постоянно увеличиваться в размере по мере его заполнения.
Обратите внимание на настройки внизу закладки:
Обязательно оставьте установленной галочку "Automatically grow file". Это позволит SQL серверу автоматически увеличивать размер файла данных по мере его заполнения. Остальные настройки оставьте по умолчанию (как на рисунке). Тогда при необходимости ваш файл данных будет увеличиваться на 10% от его текущего размера. Ставить меньшее значение не советую, так как в этом случае операции по увеличению размера файла будут происходить довольно часто, и это скажется на производительности SQL сервера.
Перейдите на закладку "Transaction Log". Вы видите те же самые поля, что и на закладке "Data Files". Здесь Вам следует указать расположение файла транзакций и его начальный размер. Руководствуйтесь теми же принципами, что и при настройке файла данных.
После указания всех параметров нажмите кнопку "ОК" и запишите базу данных.
Откройте свойства вновь созданной базы данных и перейдите на закладку "Options".
Что Вы скажете, если в результате сбоя (не важно какого) будет потеряна работа вашего предприятия за 1 день? Наверное, Вы будете не в восторге, да и все сотрудники тоже. Если такая перспектива Вас не устраивает, выбирайте модель восстановления "Full". Я пока не буду вдаваться в подробности, но выбор этой модели позволит Вам создавать архивные копии через небольшие промежутки времени при работающей программе 1С. Одно дело потерять работу предприятия за 10 минут, другое дело - за сутки.
Установите флажки остальных настроек как показано на рисунке. Ни в коем случае не ставьте флажок "Auto shrink", если только Вы не хотите периодически чувствовать провалы в скорости работы 1С. Вам незачем позволять серверу сжимать базу данных без вашего ведома.
Сохраните внесенные изменения. Измените владельца базы данных, как было описано выше. Теперь ваша база готова для работы с 1С.
Подключение базы данных к 1С
Еще чуть-чуть, и Вы сможете начать работать в SQL версии 1С. Осталось настроить подключение 1С к SQL серверу.
Запустите конфигуратор. Выберите пункт меню "Администрирование" - "Параметры базы данных SQL …":
В открывшемся окне укажите имя SQL сервера, название базы данных, которую Вы создали для работы с 1С, учетную запись и ее пароль. Если следовать моему описанию, то окно параметров базы данных SQL будет выглядеть так:
На этом глава, посвященная созданию базы данных на SQL сервере, закончена. Она получилась довольно большой, но разбивать ее на несколько частей не хотелось, так как весь материал взаимосвязан.
В следующей главе мы рассмотрим вопросы архивирования базы данных средствами SQL сервера.
Примечание: в статье отражено мое мнение по настройке сервера. Оно может не совпадать с Вашим мнением и / или мнением других специалистов.
Читайте также: