Реформа . no permission for execute access to procedure b_read_users



Здравствуйте. После обновления программы с версии 6.1.0.10 до версии 7 при запуске программы на сервере вылезает ошибкаПроцедура обновления структуры базы прошла нормально. Проверка базы показала, что ошибок нет. В программе мониторинга имя и пароль к базе SYSDBA + masterkey. Если указать FSTSUSER + Expert - та же самая ошибка при старте программы. Если в файле GDBpath.net указать вновь созданную при установке базу, то подключение проходит нормально. Система WIN XP HOME x32.Подскажите, пожалуйста, как решить проблему.Вот такие ветки нашёл себе в помощь:forum4/topic12357.htmlforum4/topic12357.html решилась выдачей прав на все процедуры в Interbase&Firebird Development Studio пользователям SYSDBA и FSTSUSER.

Если базу поднимали до 7-й версии утилитой мониторинга, при этом выставив в качестве пользователя SYSDBA, то как раз такой ситуации бы и добились: программа подключается к БД пользователем FSTSUSER, поэтому мониторинг БД тоже должен работать под этим пользователем. Либо придется, как Вы собственно и сделали, давать права на все процедуры пользователю FSTSUSER.

Я, по правде говоря, тоже пришёл к этому выводу. Но не было полной уверенности. Плюс перестройка структуры базы заняла часов где-то 15-20. На вторую попытку (успеть до понедельника) просто не осталось времени (плюс, опять же, я не быд уверен).И беда не приходит одна..Дальше начинаю патчить программу до версии 7.0.4. Программа обновляется успешно, а вот при обновлении базы ошибки:Подскажите, куда копать.

И у пользователей теперь при обновлении программы до 7 версии ошибка Hard Lock Api Error Code 19И если до 7.0.4 тоже ошибка эта же.А есть SQL папка для обновления до версии 7.0.4 через программу мониторинга?

Расширенную информацию об ошибке патч пишет в файл ...\data\UpgradeLog.txt Подозреваю что проблема все по той-же причине - подъем версии базы под пользователем SYSTEM.

UpgradeLog.txtПроделал процедуру, аналогичную первой ошибке (дал все права). Не помогло. На другом ПК постаувил 7 версию и подсунул базу от 6. Через утилиту мониторинга пробую обновить структуру - ошибка "you must be owner or SYSDBA...."Не понятно, как теперь быть. Обновить структуру могу только указав в утилите мониторинга SYSDBA, но потом не могу пропатчить до 7.0.4...Как такое можно вылечить? Сделать FSTSUSER OWNERом базы?Копии всех баз есть (боевая 6-я и заработавшая 7-я со всеми подключёнными МТСНами и ФЭРами и т.д.).

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

Я бы поднял 6-ку до 7-ки утилитой мониторинга под пользователем FSTSUSER. Не совсем понятно для каких целей Вы изменили пользователя на SYSDBA, но именно SYSDBA теперь является владельцем базы.

Похоже, что Вам уже пытались помочь: Unable to perform operation. You must be either SYSDBA or o... для нормальной работы программы-патча пользователь FSTSUSER должен быть владельцем (OWNER) базы данных... простое назначение прав не поможет

Я в предыдущем сообщении написал, что так пробовал сделать. Не получается. С этого всё и началось. Ещё в версии 5. Мне база досталась с хозяином SYSDBA два года назад.С 5 на 6 обновилось. И с 6 на 6.1.0.10 тоже.

Да, это мой пост. С тех пор и живу ремонтами баз и патчами программ из под SYSDBA. Я конечно понимал, что это был костыль, но он работал. Сейчас не проходит.Буду искать как назначить OWNER (если подскажите - будет просто замечательно).

Могу предположить, что приведенная последовательность операций не дала результат при использовании версии 2.2 программы мониторинга... попробуйте повторить ее на версии 3.0.Это самый легкий путь изменить владельца ДБ (необходимо резервировать базу под SYSDBA, если по-другому не получается, а восстанавливать - под FSTSUSER).Или можете попробовать подправить поля RDB$RELATIONS.RDB$OWNER_NAME и RDB$PROCEDURES.RDB$OWNER_NAME на FSTSUSER

Повышал базу я версией 3 утилиты мониторинга.Сейчас сделал резервирование и восстановление версией 3.0.2. После этого база дала себя обновить до версии 7.0.4. Это хорошо.Но вопрос hard lock api error у пользователей остался. На сервере смета запускается.

Reboot серверной машины решил проблему. Огромное спасибо за советы и подсказки.Знаний стало чуть побольше.

"Hardlock API Error code 19" говорит о трудностях в подключении к серверу сетевого ключа ("HL-Server", HLS32SVC.EXE). Скорее всего он "упал". В следующий раз достаточно будет запустить/перезапустить указанную службу на машине, где установлен сетевой ключ, или настроить ее (службы) автоматический запуск в случае падения.Заглядывайте в лог системных событий - не всегда, но часто, там остаются следы "происшествий", помогающие установить причину ошибки и найти решение.


Ценообразование в строительстве. ФЦЦС Минстроя. Сметный норматив. Концепция 400 дней.