no permission for execute access to procedure b_read_users

**СергейВ** Вс Май 22, 2011 17:25

Здравствуйте. После обновления программы с версии 6.1.0.10 до версии 7 при запуске программы на сервере вылезает ошибка

Процедура обновления структуры базы прошла нормально. Проверка базы показала, что ошибок нет. В программе мониторинга имя и пароль к базе SYSDBA + masterkey. Если указать FSTSUSER + Expert - та же самая ошибка при старте программы. Если в файле GDBpath.net указать вновь созданную при установке базу, то подключение проходит нормально.

Система WIN XP HOME x32.

Подскажите, пожалуйста, как решить проблему.

Вот такие ветки нашёл себе в помощь:
forum4/topic12357.html
forum4/topic12357.html
http://smeta.com/viewtopic.php?f=4&t=5898&p=36867

Ваша реклама

**СергейВ** Вс Май 22, 2011 17:40

Проблема решилась выдачей прав на все процедуры в Interbase&Firebird Development Studio пользователям SYSDBA и FSTSUSER.

**Mikle** Вс Май 22, 2011 21:07

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

**СергейВ** Вс Май 22, 2011 21:41

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

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

Подскажите, куда копать.

**СергейВ** Вс Май 22, 2011 22:30

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

**Mikle** Пн Май 23, 2011 7:14

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

**СергейВ** Пн Май 23, 2011 10:19

UpgradeLog.txt

23/5/2011: 10/7: Запуск программы
23/5/2011: 10/7: Патч к Smeta.ru версии 7.0.0.4
23/5/2011: 10/7: Содержит:
23/5/2011: 10/7: - Обновление базы
23/5/2011: 10/7: - Обновление программы
23/5/2011: 10/7: - Модули расширения
23/5/2011: 10/7: - Отчеты Excel
23/5/2011: 10/7: Старт автоматического определения установленных компонент.
23/5/2011: 10/7: Путь запуска: C:\Documents and Settings\vlasov\Рабочий стол\7.0.0.4\Smeta.ru\
23/5/2011: 10/7: Имя компьютера: b265
23/5/2011: 10/7: Протокол TCP/IP установлен
23/5/2011: 10/7: Версия патча: 7.0
23/5/2011: 10/7: Считано из реестра: Версия - "7.0" Путь - "C:\StroySoft\Server\Base\DataSD.ssd"
23/5/2011: 10/7: Исполняемый файл клиента: c:\stroysoft\Smeta.ru\Client\SmetaRu.exe
23/5/2011: 10/7: Автоматическое определение установленных компонентов завершено
23/5/2011: 10/8: Старт обновления
23/5/2011: 10/8: Обновление программы ..........
23/5/2011: 10/8: Обновление программы успешно завершено
23/5/2011: 10/8: Обновление ресурсов программы ..........
23/5/2011: 10/8: Регистрация ресурсов программы в реестре ....
23/5/2011: 10/8: Регистрация ресурсов программы в реестре успешно завершена
23/5/2011: 10/8: Обновление ресурсов программы успешно завершено
23/5/2011: 10/8: Обновление модулей расширения ..........
23/5/2011: 10/8: - Плагин ExpArps.dll Версии идентичны (6.2.0.6 = 6.2.0.6)
23/5/2011: 10/8: - Плагин ExpImpObj.dll Версии идентичны (7.0.0.10 = 7.0.0.10)
23/5/2011: 10/8: - Плагин ImpArps.dll Версии идентичны (7.1.0.0 = 7.1.0.0)
23/5/2011: 10/8: - Плагин ImpSm2000.dll Версии идентичны (7.0.0.1 = 7.0.0.1)
23/5/2011: 10/8: - Плагин ImpVCPlg.dll Версии идентичны (6.2.0.8 = 6.2.0.
23/5/2011: 10/8: Обновление модулей расширения успешно завершено
23/5/2011: 10/8: Обновление отчетов Excel ..........
23/5/2011: 10/8: Обновление отчетов Excel успешно завершено
23/5/2011: 10/8: Старт обновления Firebird UDF из каталога C:\Documents and Settings\vlasov\Рабочий стол\7.0.0.4\Smeta.ru\Data\Udf
23/5/2011: 10/8: Определен стандартный каталог Firebird UDF: "C:\Program Files\Firebird\Firebird_2_5\udf\"
23/5/2011: 10/8: Проверка необходимости обновления UDF успешно завершена:
23/5/2011: 10/8: Обновление UDF - НЕТ.
23/5/2011: 10/8: Рестарт сервера - НЕТ.
23/5/2011: 10/8: Обновление Firebird UDF успешно завершено.
23/5/2011: 10/8: Старт обновления базы № 1 (c:\=server3\datasd_7_ful.ssd)
23/5/2011: 10/12: unsuccessful metadata update
MODIFY RDB$PROCEDURES failed
no permission for protect access to PROCEDURE DM_GETNORMOBASELIST

C:\Documents and Settings\vlasov\Рабочий стол\7.0.0.4\Smeta.ru\Data\BaseUpgr.sql

create or alter procedure DM_GETNORMOBASELIST
returns (
BASEID integer,
STATE integer)
AS
begin
--TO DO
end

23/5/2011: 10/12: Не удалось обновить базу № 1
23/5/2011: 10/12: Завершение работы программы обновления

Проделал процедуру, аналогичную первой ошибке (дал все права). Не помогло.

На другом ПК постаувил 7 версию и подсунул базу от 6. Через утилиту мониторинга пробую обновить структуру - ошибка "you must be owner or SYSDBA...."

Не понятно, как теперь быть. Обновить структуру могу только указав в утилите мониторинга SYSDBA, но потом не могу пропатчить до 7.0.4...

Как такое можно вылечить? Сделать FSTSUSER OWNERом базы?

Копии всех баз есть (боевая 6-я и заработавшая 7-я со всеми подключёнными МТСНами и ФЭРами и т.д.).

**СергейВ** Пн Май 23, 2011 11:00

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

[0005684] 7.0\_pte.sql (3829)
[0005685] 7.0\_pte.sql (3830)
[0005686] Сохранение изменений
[0005687] gbak: ERROR:Unable to perform operation. You must be either SYSDBA or owner of the database
[0005688] gbak:Exiting before completion due to errors

**Mikle** Пн Май 23, 2011 11:18

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

**Semenov** Пн Май 23, 2011 11:50

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

**СергейВ** Пн Май 23, 2011 11:53

Я в предыдущем сообщении написал, что так пробовал сделать. Не получается.

You must be either SYSDBA or owner of the database

С этого всё и началось. Ещё в версии 5. Мне база досталась с хозяином SYSDBA два года назад.

С 5 на 6 обновилось. И с 6 на 6.1.0.10 тоже.

**СергейВ** Пн Май 23, 2011 11:57

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

**Semenov** Пн Май 23, 2011 12:04

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

**СергейВ** Пн Май 23, 2011 16:21

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

Но вопрос hard lock api error у пользователей остался. На сервере смета запускается.

**СергейВ** Пн Май 23, 2011 16:44

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