Comments 16
Смещение дат ставьте 2000, чтобы не получить потом проблем с «пустыми датами». Вроде в 2008 еще не сделали по человечески. Из-за этого при попытке загрузить документ в котором дата < 1753 года, например из-за опечатки получился «211 год» — загрузка не сможет пройти. Ну а так — кроме грабель переименования компьютера — ничего сверх того, что есть в прилагаемой к 1с книге из сотни страниц «Клиент-сервер. Особенности установки и использования» нету. Ну и в этой книге еще и про особенности postgre sql, db2, сервера для линукса написано.
Ну а про бэкапы — в мануалах к скулю, да.
Ну а про бэкапы — в мануалах к скулю, да.
Хотя, конечно, популяризации 1с на хабре рад.
Про 211 год — такое может произойти, например, в распределенной базе, в которой другой узел на чем угодно, кроме MS SQL, т.е. файловый, на Postgre, на DB2. А из-за такой мелочи встанут обмены, придется искать этот документ, а ведь дата кривая может быть в любом реквизите.
После создания это смещение уже не изменить, только через выгрузку в .dt, удаления базы в скуле, создания новой с правильным смещением, загрузки .dt, а это долго.
После создания это смещение уже не изменить, только через выгрузку в .dt, удаления базы в скуле, создания новой с правильным смещением, загрузки .dt, а это долго.
Нет смысла создавать базы под встроенным пользователем SA. Достаточно создать в MSSQL нового пользователя и дать ему права на создание баз. В этом случае при создании через сервер предприятия он будет автоматически владельцем, и можно регулировать области доступа к разным базам с нескольких серверов. Ну и вообще это идеологически правильнее.
Если мне не изменяет память, 1С 8.2 не работает с mssql если там выставлена аутентификация только по доменным учетным записям, необходимо выставлять обязательно смешанную аутентификацию. Доменные учетки использовать при этом можно.
Если мне не изменяет память, 1С 8.2 не работает с mssql если там выставлена аутентификация только по доменным учетным записям, необходимо выставлять обязательно смешанную аутентификацию. Доменные учетки использовать при этом можно.
Да. Наверное учеткам в моем посте было бы правильно уделить больше внимания. Спасибо за правильные дополнения.
Идеологически правильнее создавать базу вручную и не давать owner'у 1сной базы право на создание баз.
И 1С 8.2 работает без смешанной аутентификации, просто нужно оставлять пустое имя пользователя и пароль, в принципе смешанная аутентификация — тоже брешь в безопасности и идеологически не совсем верно.
И 1С 8.2 работает без смешанной аутентификации, просто нужно оставлять пустое имя пользователя и пароль, в принципе смешанная аутентификация — тоже брешь в безопасности и идеологически не совсем верно.
Чем может быть опасно создание баз owner'ом, который заведен отдельным аккаунтом? Пользователи в любом случае не имеют права создавать базы, для этого они должны знать данный логин и пароль. А для исполнения повседневных обязанностей он им не нужен.
По поводу пустого имени пользователя и пароля немного недопонял. Где вы предлагаете их оставлять, при создании базы на сервере предприятия?
По поводу пустого имени пользователя и пароля немного недопонял. Где вы предлагаете их оставлять, при создании базы на сервере предприятия?
А зачем ему право что-либо создавать? Идеологически — право это лишнее, значит оно не нужно.
Да, не мешает, но всё-таки оно не нужно.
При создании базы, если имя пользователя и пароль не заполнены, сервер 1с пытается использовать сервер SQL от текущего Windows-пользователя (пользователя, от имени которого запущен сервер 1С).
Я надеюсь, у вас он не запускается от имени Local System или локального USR1CV82?
Кстати, для служб (для того же сервера 1С), если у вас уровень домена 2008 R2, рекомендую использовать Managed Service Accounts — тут не нужно заботиться о хранении паролей пользователя, истечении сроков давности паролей, политиках домена для этого и т. п.
Да, не мешает, но всё-таки оно не нужно.
При создании базы, если имя пользователя и пароль не заполнены, сервер 1с пытается использовать сервер SQL от текущего Windows-пользователя (пользователя, от имени которого запущен сервер 1С).
Я надеюсь, у вас он не запускается от имени Local System или локального USR1CV82?
Кстати, для служб (для того же сервера 1С), если у вас уровень домена 2008 R2, рекомендую использовать Managed Service Accounts — тут не нужно заботиться о хранении паролей пользователя, истечении сроков давности паролей, политиках домена для этого и т. п.
Все зависит от количества баз и частоты их добавления. Вполне возможна ситуация, когда более удобным является выдача права на создание баз пользователю, чем вручную создание баз на сервере SQL и назначении на каждую из созданных баз owner заново. Чем больше количество операций в процессе создания базы 1С, тем больше вероятность ошибки. Это тоже нужно учитывать при создании регламента добавления базы.
У меня почему-то не сработал кейс по включению в SQL Server 2008 «Windows Authentication mode» Даже если в этом случае пользователь, который подключается к базе SQL со стороны 1С является owner-ом данной базы — подключение не происходит. Вполне допускаю свою ошибку в данном процессе. пытался сейчас найти пруф, но не могу. Если найду — отпишусь.
MSA действительно достаточно удобная штука.
У меня почему-то не сработал кейс по включению в SQL Server 2008 «Windows Authentication mode» Даже если в этом случае пользователь, который подключается к базе SQL со стороны 1С является owner-ом данной базы — подключение не происходит. Вполне допускаю свою ошибку в данном процессе. пытался сейчас найти пруф, но не могу. Если найду — отпишусь.
MSA действительно достаточно удобная штука.
1) А, ну я видимо не понял про создание баз. Если у вас действительно разработчики, которые периодически создают кучу баз — то да, ваш подход вернее. У нас всего пара баз, которые созданы раз и навсегда.
3) У нас сервер 1С запускается из-под MSA, и этот же доменный аккаунт добавлен в SQL2008R2.
Попробуйте ради интереса сделать так: дать доменному юзеру в SQL роль с полными правами sysadmin, проверьте, есть ли подключение. Если есть — значит всё ок аутентифицирует, но просто проблемы в правах юзера.
3) У нас сервер 1С запускается из-под MSA, и этот же доменный аккаунт добавлен в SQL2008R2.
Попробуйте ради интереса сделать так: дать доменному юзеру в SQL роль с полными правами sysadmin, проверьте, есть ли подключение. Если есть — значит всё ок аутентифицирует, но просто проблемы в правах юзера.
Ошибка при создании информационной базы: Ошибка при выполнении операции с информационной базой: Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Login failed for user 'Domain_1\user123'.
HRESULT=80040E4D, SQLSrvr: Error state=1, Severity=E, native=18456, line=1
Пользователь в список пользователей добавлен, роль sysadmin у него есть, база создана и он является ее владельцем. В статусе пользователя разрешены подключения к БД, логин включен.
Чего-то видимо другого не хватает.
Microsoft OLE DB Provider for SQL Server: Login failed for user 'Domain_1\user123'.
HRESULT=80040E4D, SQLSrvr: Error state=1, Severity=E, native=18456, line=1
Пользователь в список пользователей добавлен, роль sysadmin у него есть, база создана и он является ее владельцем. В статусе пользователя разрешены подключения к БД, логин включен.
Чего-то видимо другого не хватает.
Не забывайте в регламентные задания SQL Server добавлять бэкап transaction лога.
Во-первых, это позволяет восстанавливать базу на любой момент времени.
Во-вторых, без бэкапа transaction лог будет все время расти.
Ну или ставьте базу в режим восстановления simple :-)
Во-первых, это позволяет восстанавливать базу на любой момент времени.
Во-вторых, без бэкапа transaction лог будет все время расти.
Ну или ставьте базу в режим восстановления simple :-)
Sign up to leave a comment.
1С сервер 8.2 + MsSql 2008 + BackUp