Доброго времени суток!
OS: Scientific Linux 4.4
ядро РедХат 2.6
IDS for Linux 7.30.UC10
Проблема:
при выполении скуэла такого плана, под юзером informix -
grant dba "sasha" ;
grant dba "scsi" ;

create role "dov_v" ;
.....
выводит ошибку :
*** execute sqlobj
19800 - Role name already exists as a user or role.

сервер поднят с нюля, ролей там быть не может по определению...
понимаю, что это связано с тем, что где-то не розданны права на все обьекты БД как суперюзеру,
но не могу найти решение этой проблемы
Прошу помощи....
Спасибо.

Танselect * from sysusers where username = 'dov_v'

чего и следовало ожидать:
No rows found

а если дать select * from sysusers where username = 'nformix'
то выводит такое :
username usertype priority password
informix D 9
=================
еще раз повторюсь сервер с нуля, других БД нету, создание таблиц, хранимых процедур, заливка данных проходит на ура.... затык именно по ролям.....

на UnixWare 7 и IDS 7.30 такая глюка встречалась если в ОС был юзер admin, а в ролях присутствовала строчка create role "admin". в этом случае проблема решалась просто убиванием этой строки.
на линухе создание ЛЮБОЙ роли приводит к описаной ошибке.

ПЛС, подскажите куда копать!
спасибо.

проблемы с тем что сервер еще не в сети....
а по сути вопроса?

Журавлев Денисиз в dbaccess воспроизводится? Вообще на какую строку ругается? ничего не понятно
grant dba "scsi" -- это вообще syntax error.
scsi - взято для примера, не подумал что зарезервированно слово
такой пример подойдет?
{ DATABASE spov_1 delimiter | }

grant dba to "informix";
grant dba to "dbaspov";
grant dba to "in1";
grant dba to "in2";
grant dba to "in3";
grant dba to "in5";
grant dba to "in6";
grant dba to "in7";
grant dba to "in10";
grant dba to "in8";
grant dba to "in9";
grant dba to "in12";
grant dba to "in4";
grant dba to "in14";
grant dba to "in15";
grant dba to "in16";
grant dba to "in17";
grant dba to "in18";
grant dba to "in19";
grant dba to "in13";
grant dba to "in11";
grant dba to "in20";
grant dba to "in21";
grant dba to "in22";
grant dba to "in23";
grant dba to "in24";
grant dba to "in25";

create role "_default" ;
create role "drfo_v" ;
create role "ok13r_e" ;
create role "pck_del" ;
create role "pck_e" ;
create role "pck_v" ;
create role "rd_e" ;
create role "rd_v" ;
create role "rpt_anal" ;
create role "pck_crct" ;
create role "admin" ;

grant "_default" to "dbaspov" ;
grant "_default" to "in1" ;
grant "_default" to "in10" ;
........
выбивает сразу за create role "_default" ;
в dbaccess - таже ошибка

Журавлев Денис scsi_bes Журавлев Денисиз в dbaccess воспроизводится? Вообще на какую строку ругается? ничего не понятно
grant dba "scsi" -- это вообще syntax error.
scsi - взято для примера, не подумал что зарезервированно слово
такой пример подойдет?
млин. ну ё. Это не зарезервированное слово. там to не хватает.


какое to???? приведенный пример взят с полностью рабочего скрипта восстановления базы на ЮниксВаре 7 и ИДС 7.30, работает полностью....
я ошибку спрашиваю по креат роле а не grant... грнты отрабатывают .....

выполнял :
select * from sysusers ;
create role 'dov_v';
результат:
username usertype priority password

informix D 9
public C 5

create role "dov_v" ;
*** execute sqlobj
19800 - Role name already exists as a user or role.

результат дбимпорта:
{ DATABASE spov_1 delimiter | }

grant dba to "informix";
grant dba to "dbaspov";
grant dba to "marina";
grant dba to "yulya";
grant dba to "sveta";

create role "drfo_v" ;
*** execute sqlobj
19800 - Role name already exists as a user or role.
ни "dov_v" ни "drfo_v" в ОСи нету (или предоствить пустой файл от команды греп?) , перечень юзеров из сисмастера приведен выше....

Журавлев Дениса кстати пользователем/паролем вообще к серверу можно подключится? Не без пароля локально, а именно с паролем.

нет... dbaccess > Connection > USER NAME >> informix
Enter the login name you

-----------------------
spov
onspov

952: User's password is not correct for the database server.
===========
ошибка в наборе логина и пароля исключена...
думал этим позже разобраться....

Журавлев Денис scsi_bes

952: User's password is not correct for the database server.
===========
ошибка в наборе логина и пароля исключена...
думал этим позже разобраться....
в общем отключайте md5 и shadow. Слишком древний информикс и новый линукс.

это совет по подключению или все вместе взятое? это поможет решить проблему с ролями?
за совет спасибо.

Журавлев Денис
Я вам щаз другой дам: возьмите ids7.31ud6

в нем решена проблема с мд5 и шадоу?
ЮВаре 7 понимает мд5 и шадоу
под рукой работающий сервер на ЮВаре и ИДС7.30
поясню суть вопроса почему вылезли эти грабли....
в нашей организации БД основаны на ИДС7.30 и ЮВаре 7.01
7 лет впринципе стабильной работы.
софт пишет сторонняя организация, в плане - перевод БД на Оракл.
Но до этого момента нам надо подержаться наплаву при учете того что все инсталы и дрова заточены под ЮВаре и ИДС7.30. ЮВарь не понимает нового железа, а комплектующие к старому уже давно не производят.
у разработчиков уволились спецы по ИДС, просить у них помощи без результатно.первое - им за это не платят,второе- ожидается миграция на оракл.
были взяты СЛ44 и найден ИДС7.30 для линукса.
проинсталились - внешне все хорошо, дбимпорт вливает если убрать все что касаемо ролей.
только пытаешься сделать роль - ошибка....

Тогда вопрос поставим по другому:
как сильно изменился синтаксис у 9.хх и 10.хх от 7.30? в плане хранимых процдур...
будут ли корректно работать процедуры заточенные под 7.30, если дбэспортом выгрузить БД из 7.30 и загрузить через дбимпорт в 9.хх или 10.хх?

и все таки хотелось бы понять причину ошибки с ролями....

leonx2без разработчиков вы не смигрируете с 7.30 на 9.х или 10.0
старый синтаксис остался, но есть ньюансы в работе хранимых процедур. Самое безболезненное - это все-же уйти на 7.31

P.S. Мы мигрировали с 7.31 на 9.40 - разработчикам пришлось поправить десяток процедур(различия в вызове при опускании необязательных аргументов, и.п.) ну и в части производительности(другой работы оптимизатора) пришлось потрудится.

спасибо.
в чем существенное различие 7.30 и 7.31?

Журавлев Денис
в общем отключайте md5 и shadow. Слишком древний информикс и новый линукс.
спасибо, коннект прошел локально после отключени мд5, шадоу остался включен

но коннект сути сабжа не изменил.....
есть 2 новых вопроса:
1й - может ли являться ошибка по креат роле следствием прописанной ДБ_Локали?:
http://www.sql.ru/faq/faq_topic.aspx?fid=541Примечание:
Не рекомендуется устанавливать свои локали перед первичной инициализацией дискового пространства сервера (oninit -i), во время которого создаются системные БД sysmaster и sysutils. Эти системные базы должны быть с локалями по умолчанию
DB_LOCALE=EN_US.8859-1 или DB_LOCALE=EN_US.819
2-й мне был предложен вариант по искуственной замене креат роле на такой финт ушами:
авторзамiсть CREATE ROLE 'dov_v'; пишеш
insert into sysusers (username, usertype,
priority) values ('dov_v','G',5);
це одне й те ж
вопрос: кошерна ли такая замена?

спасибо, я это читал.... вопрос не в том как трактует это IBM, а в применении к моей ситуации...
Тан
Я бы на вашем месте все перепроверила раза 3-4, а потом попросила бы кого-нибудь еще проверить все снова

если Вы по поводу проверки имён - еще раз повторяю НЕТ В СИСТЕМЕ И В БД ДАЖЕ НАМЕКА НА ТАКИЕ ИМЕНА .
сорри.... я ж не малый ребёнок.....проверили не смотря на то, что система только поднята.

единственное на что могу грешить - на локаль перед онинитом....
сейчас переставим систему и информикс по новой но ужо без локали на этапе инициализации...
посмотрим на результат

Танспасибо, что крикнул, теперь я поняла
прошу прощения, я просто акцентировал Ваше внимание что в 10й раз напоминать про имена не стоит :)
еще раз прошу прощения.

как пример - есть 3 разные организации которые наступили на эти грабли, решения , кроме как описано выше, - не нашли.

Журавлев Денисшадоу отключить не?
на Юваре проверили - работает с шадоу
на СЛ4.4 с шадоу - коннектится
или есть предположение что из-за шадоу некорректно обрабатывает файл passwd?
и встречный вопрос: на старой системе клиент одновременно создает 3 коннекта(так надо по ПО).
онстат -у выглядит так:
8c5b9a5c Y--P--- 74 Ludmila LUDMILA 8c824744 0 1 11 0
8c5b9f10 Y--P--- 78 Ludmila LUDMILA 8c8fc1f8 0 1 51 33
8c5ba3c4 Y--P--- 76 Ludmila LUDMILA 8c83c658 0 1 43552 44039

нашел интерестную строку в файле sqlhosts
obloks onipcshm obloks abc
onobloks ontlitcp obloks sqlexec
не понятно назначение abc , к чему оно?

поставили систему по новой.
не прописывали ДБ_локаль и др. локали
отключили мд5 и шадоу
происталили ИДС
на креат роле таже грабля.......

zefsзаменяем строку
scsi_bes
...
create role "dov_v" ;
.....


на
grant connect to "dov_v" ;
update sysusers set usertype='G' where username="dov_v" ;

далее всё работает нормально во всяком случае у нас не было проблем с ролями, которые были созданы таким способом!

спасибо, сделали по своему через инсерт
учтем и этот вариант.

на РедХате с тем же пакетом ИДС в другой организации - те же проблемы с ролями
мне не понятна ситуация когда на юваре запускаю
select grantor, grantee, tabid, tabauth,
dic_tabid,dic_tabname,dic_ownername,dic_dbname
from systabauth,sysdic
where tabid=dic_tabid and dic_tabname='sysusers'
результат такой:
informix|public|7|s-------|7|sysusers|informix|oks|
informix|public|7|s-------|7|sysusers|informix|spov_x|
informix|public|7|s-------|7|sysusers|informix|sysmaster|
informix|public|7|s-------|7|sysusers|informix|sysutils|
=====
тотже запрос на СЛ44 и РХ даёт такой рез-т:
informix|public|7|s-------|7|sysusers|informix|oks|
informix|public|7|s-------|7|sysusers|informix|spov_x|
не отображает что такие таблицы в сисмастере и сисутилс есть, а они таки там есть....

мы пришли к выводу что 19800 ошибка - баг для 7.30 под ОС Линукс(описанный в пофиксенных для версии 9.30)
или укажите в каком месте мы что-то делаем не так.....
спасибо ВСЕМ!