Доброго времени суток.
Печаль случилась следующая:при пакетном обновлении базы (первый раз так обновлял базу), 1с установила блокировку соединений с информационной базой. Кода разблокировки я не ставил, но на всякий случай перепробовал все возможные варианты с ключом \UC. Всё бы ничего, но через консоль не могу так же снять блокировку, т.к. нет у меня пароля для доступа к инф базе через консоль (тут не всё так просто, ни как не докричусь до человека, который до меня управлял всем этим хозяйством). Так же прописывал в ярлыке "/CРазрешитьРаботуПользователей /UCПакетноеОбновлениеКонфигурацииИБ" (без кавычек конечно), и вот тут само интересное пишет "У текущего пользователя нет доступных ролей, для запуска информационной базы", при этом у текущего пользователя полные права на базу на самом деле. Точно так обновлял в тот же день другую, точно такую базу, с этим ключом все нормально запустилось и работает, а тут, видимо глюк произошел или еще что, не знаю.
Откат системного времени не помог, база просто сделала вид, что в системе нет пользователей (думал слетели пользователи каким то чудом при обновлении, проверил на других, не тронутых базах, там так же небыло пользователей, вернул системное время обратно - всё вернулось в исходную точку).
Теперь не знаю как мне подобраться к базе. Скорей всего есть какие то скрипты обходные, которые пусть и не снимут пароль с инф базы в консоли, но хотябы галочку блокировки убрать.

P.S. База 1С 8.2 ЗиК, клиент-серверный вариант.
P.S.S. Перечитал за 2 дня кучу форумов и статей, нужного себе не нашел, везде срабатывал один из выше перечисленных вариантов.
P.S.S.S. ПОМОГИТЕ!!! XD

в консоли доступ именно к БАЗЕ - юзер и пароль из базы 1с самой, с полными правами. пароль к кластеру - уже другое

"Право Администрирования" разрешает доступ к конфигуратору и к базе в консоле.

в консоли удали базу (в режиме оставить SQL базу) и создай заново

зы
вероятная причина твоего сабжа - блокировка или отсутствие доступа файлов настройки сервера 1с

(1) Пробовал - "Ошибка сетевого доступа к серверу"

(4) это совсем другая ошибка, не связанная с блокировкой

(3) А вот удалять и создавать заново (тут я сильно ступил, некогда было делать копию базы перед обновлением, срочно нужны были новые формы)

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

Может попробовать сделать бекап средствами SQL и затем создать новую БД из этого бекапа

(5) Там несколько баз, все на одном сервере, ко всем есть доступ, где мне известны пароли, а тут вылетает такая ошибка "Ошибка получения параметров информационной базы: server_addr=tcp//тра-ля-ля = Ошибка сеиевого доступа к серверу. Удаленный хост принудительно разорвал существующее подключение."

(7), (8) Сейчас попробую

в файловой создается файлик, который надо просто удалить.
в клиент-сервере также наверное

(имхо) У тс проблемы несколько другого плана. Они не связанны с блокировкой соединения, а - "спровоцированы" установкой блокировки.

(12) почему-то сервер 1с не дает изменять (а точнее не принимает изменения) часть параметров конфигурационного файла, в частности у меня нельзя изменить пароль пользователя скуля...

Думаю что где-то есть кеш и именно от туда растут ноги сабжа...

(13) +1

кэш службы 1с известно где вроде...

(12), (13) какой выход из такой ситуации тогда возможен? Удаление кэш файлов?

наеврняка - переставить серверную часть 1с, имхо

невзлетит

Свежие сведения:
1. Серверная часть работает нормально, т.к. все другие базы в полном порядке.
2. 1С выполняет аутентификацию пользователя так же нормально (запуск с ключами /N /P /UC проходит), но упирается в какую то строчку в кофигурации, где проходит проверка ролей и как итог говорит о том, что у текущего пользователя нет доступных ролей для открытия информационной базы, если пишу другие логин/пароль то ничего не говорит, перезапрашивает просто, т.е. пара логин/пароль верные.
3. Консоль работает нормально, т.к., опять-же, на других информационных базах нормально дает возможность менять настройки, а на этой базе с любой парой логин/пароль выдает выше указанное "Ошибка получения параметров информационной базы: server_addr=tcp//тра-ля-ля = Ошибка сетевого доступа к серверу. Удаленный хост принудительно разорвал существующее подключение."

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

P.S. (18) Взлетит, ни куда нафиг не денется))))

Очень надеюсь на вашу помощь, друзья и коллеги

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

(21) Найти строку не проблема, проблема подключиться для редактирования

Коллеги, помогите решить проблему. Я новичок еще в 1С программировании, а с sql вообще сталкивался постольку-поскольку.

с кэшом  что удалил ?

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

(21) Если так. То попробуй, удали локальный кэш.
c:\Documents and Settings\<user>\Application Data\1C\1Cv82\ <папка>

Посмотри права пользователя. Для входа в режиме предприятия должны быть полные права или роль Пользователь.

Если удается войти в конфигуратор, то попробуй сделать резервную копию и создать новую базу из копии. С испорченной на досуге разберешься.

Пользователи в списке выбора есть? Если нет, возможно в бд на sql слетели пользователи.

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

(27) >Пользователей в списке нет
Видимо слетели
v8: Слетели полные права у всех пользователей

(28) Спасибо, сейчас попробую такой вариант

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

(29) Неаккуратная работа в бд sql может привести к уничтожению БД, так что смотри, лучше сделай копию средствами sql.

(0) Ну, лечилось - бэкап средствами SQL, подъем новой базы на SQl-сервере, регистрация новой базы на сервере приложений, далее...

(31) Сделал бэкапник))
(28) Не вышло
(32) Это уже пробовал
(30) Попробую так, только нужно гугл помучить еще на предмет копирования скуль таблиц)

Всем большое спасибо. Взлетело. Но база оказалась убитой. Придется все восстанавливать за месяц вручную... [дальше лексика сильно нецензурного характера]

(34) Если sql база была настроена на полное сохранение, то можно восстановить базу на нужное время по журналу транзакций.

(35) к сожалению все бэкапники вручную покачто делаются.

(0) попробуй "/CРазрешитьРаботуПользователей password" и слово password не надо менять

(37) вернее так /CРазрешитьРаботуПользователей /UCpassword

(35) Это не бекап, это журнал. Посмотри на всякий случай в свойствах БД модель восстановления.

(38) Разблокировать мне её удалось, методом (28) к стати говоря. Там при обновлении ошибки в самой базе произошли, как именно так и не понял, на одной базе всё ок, а на второй обрушилась нафиг.

(39) Сейчас посмотрю

(39) установлен параметр "полная". Как можно восстановить?

(39) Восстановление - пункт "Журнал транзакций" неактивный

(42) Возможно повезло. Дальше не могу помочь, не восстанавливал.
Если тут не помогут, зайди на sql.ru, возможно там подскажут.
Но в любом случае перед восстановлением сделай копии...

бэкапы автоматизируй чтоб граблей небыло

Спасибо еще раз всем большое)) Там оказалось что ручное восстановление пару дней займет)
Надо бэкапами заняться серьезней