IDS 9.40 UC3
Есть база svodka.
Есть хранимая процедура "deposit".depo()
И смотрится она нормально.
При dbexport'е эта процедура почему то становится "deposit".depo"deposit".depo()
При этом все остальные процедуры нормально.
С чем это может быть связано?

vasilisА что выдает такой запрос ?
------------------------------------------
-- Procedure Info
--
-- V.Shulzhenko DBA_Tools
------------------------------------------
select '===== sysprocedures =====' _______________
,p.*
,'-- sysprocauth --' _________
,a.*
,'-- sysprocplan --' _________
,(select unique created from sysprocplan l
where p.procid=l.procid) date_created_plan
,(select sum(datasize) from sysprocplan l
where p.procid=l.procid) plan_size
from sysprocauth a,sysprocedures p
where p.procid=a.procid
and p.procname matches
'depo*'
order by 1

procname depo_stat_to_dbf
owner son
procid 242
mode D
retsize 714
symsize 1561
datasize 2933
codesize 268
numargs 0
isproc f
specificname
externalname
paramstyle I
langid 2
paramtypes
variant t
client f
handlesnulls t
iterator f
percallcost 0
commutator
negator
selfunc
internal f
class
stack
parallelizable f
costfunc
selconst 0.00
collation ru_RU.915
_________ -- sysprocauth --
grantor son
grantee public
procid 242
procauth e
_________ -- sysprocplan --

date_created_plan 31/08/2005
plan_size 215

vasilisА что выдает такой запрос ?
------------------------------------------
-- Procedure Info
--
-- V.Shulzhenko DBA_Tools
------------------------------------------
select '===== sysprocedures =====' _______________
,p.*
,'-- sysprocauth --' _________
,a.*
,'-- sysprocplan --' _________
,(select unique created from sysprocplan l
where p.procid=l.procid) date_created_plan
,(select sum(datasize) from sysprocplan l
where p.procid=l.procid) plan_size
from sysprocauth a,sysprocedures p
where p.procid=a.procid
and p.procname matches
'depo*'
order by 1

Вот это с того сервера.
Это именно то.
А то было с друго, с сервера разработчиков.

_______________ ===== sysprocedures =====
procname depo_stat_to_dbf
owner son
procid 242
mode D
retsize 714
symsize 1561
datasize 2933
codesize 268
numargs 0
isproc f
specificname
externalname
paramstyle I
langid 2
paramtypes
variant t
client f
handlesnulls t
iterator f
percallcost 0
commutator
negator
selfunc
internal f
class
stack
parallelizable f
costfunc
selconst 0.00
collation ru_RU.915
_________ -- sysprocauth --
grantor son
grantee public
procid 242
procauth e
_________ -- sysprocplan --
date_created_plan 10/09/2005
plan_size 217

vasilis Sleeping Daemon
Есть хранимая процедура "deposit".depo()

Что то я не понял из представленной информации - где все таки процедура depo в этой базе ?
Когда говорится "deposit".depo() то предполагается, что deposit это имя владельца процедуры, а depo - непосредственно имя процедуры.
Похоже, что процедуры или уже нет или ее имя достаточно хитрое.
Попробуй в запросе подставить имя для поиска, как
'*depo*'
и из результаты выбери только нужную процедуру, если она там появится.
Хм. А нет ничего.
Странно все это.
dbaccess смотрю - есть хранимки.
son.balcode_to_dbf son.listp_to_dbf son.soogu_to_dbf

bubka.bank_to_dbf son.listw_to_dbf son.soogu_to_dbf

son.cur_stat_to_d+ son.md_dbf_to_dbf son.svod_us

deposit.depo son.okonh_to_dbf

son.depo_stat_to_+ son.okonh_to_dbf

son.doctype_to_dbf son.opf_to_dbf

son.issuer_to_dbf son.partstat_to_d+

son.issues_to_dbf son.primstat_to_d+

son.kfs_to_dbf son.quota_to_dbf

А скрипт ничего не находит.
А как deposit имя владельца, если такого пользователя в системе нет?

vasilisА что девелоперы говорят на эту тему ? Должна быть такая процедура depo или нет ? Если ее текст присутствует, то можно попробовать дропнуть и создать процедуру заново.
Прочекать БД на предмет целостности...
Девелоперы говоря не знаем. Я им посоветовал переименовать процедуру в depo_чего_то_там. Мля, они говорят мы не знаем как.

Такая процедура вообще есть.
Напомню, при dbexport'е эта процедура становится в таком виде:
"deposit".depo"deposit".depo() вместо "deposit".depo()

vasilisКтсати, скрипт с маской '*depo*' нужно выполнить под informix-ом.
Это так и было сделано ?

А переименование процедуры происходит путем удаления старой и создания новой :)
Я даже проверил не является ли depo зарезервированным словом для 9.4 - оказалось нет, слово разрешенное, как и deposit...
Из под информикса. Другого доступа у меня в принципе нет.
Сегодня пришла разработчица, которая крэйтила эту процедуру.
Сказал что бы переименовла.
Переименовать не сложно, сложнее найти, где ссылки на неё и там переименовать.
Спасибо за помощь.

vasilis Sleeping DaemonПереименовать не сложно, сложнее найти, где ссылки на неё и там переименовать.
ServerStudio рулит - можно найти все вхождения в тексты процедур, триггеров, view.

А что все таки дала проверка oncheck-oм ?
Ведь причина то интересна.... Возможно, в имя попал какой то символ с кодом из второй половины таблицы, возможно кто то ручками правил системные таблицы, возможно просто во время создания был какой то сбой...
Я не проверял oncheck'ом.
Эта процедера номально работет. И в базе она видимо нормально? сидит.
Может это неадекватное поведение dbexport'а? У меня пока идея поменять имя процедуры на depo_xxxx. Программисты как то не проявляют интузазизм этого делать, придется все процедуры, связанные с этой лопатить.
Хотя это можно сделать в файле снятым дбсхемой сделать.

После "ручного" исправления sql файла(под linix'ом) dbimport поднимет базу нормально. Только меня достали эти "ручные" исправления и кроме того не ясно, какой сюрприз может быть преподнесен в дальнейшем.
База поднимается переодически dbimport'ом, раз в квартал на резервном сервере при проведении тренинга.

Журавлев Дениса что возвращает
select p.*
from sysprocedures p
where p.procname matches 'depo*'

dbaccess дает вот это:
procname depo
owner deposit
procid 241
mode R
retsize 98
symsize 199
datasize 481
codesize 100
numargs 0
isproc f
specificname
externalname
paramstyle I
langid 2
paramtypes
variant t
client f
handlesnulls t
iterator f
percallcost 0
commutator
negator
selfunc
internal f
class
stack
parallelizable f
costfunc
selconst 0.00
collation ru_RU.915

Журавлев Денис Sleeping Daemon
dbaccess дает вот это:
procname depo
owner deposit
procid 241


а что возвращает:
Т.е. покажи начало процедуры, что там в create proc..... написано
Ничего не возвращет, ничего не находит.
Но dbaccess(database->info->routine) показывает вот что:

create procedure "deposit".depo()
returning decimal(18,2);

define rest decimal(18,2);
define Sclient_id int;

Foreach
select client_id, amount into Sclient_id, rest from svod_issues order by client_id

return rest
with resume;
end foreach;

end procedure
;

vasilis Sleeping Daemon Журавлев Дениса что возвращает
select p.*
from sysprocedures p
where p.procname matches 'depo*'

dbaccess дает вот это:
procname depo
owner deposit
procid 241
mode R
...
collation ru_RU.915
Интересно, оказывается мой SQL запрос не показывал эту процедуру, потому что ее нет в sysprocauth, что не совсем нормально.
И, наверное, именно поэтому и "едет крыша" у dbexport.
Поэтому стандартная перезагрузка процедуры (пересоздание) должна помочь.
А dbexport -> правка этой процедуры -> dbimport должны помочь?
Если должны - то не помогли. Переносил я с одного сервера на другой все базы недавно. Так при dbexport'е уже с нового сервера эта бодяга осталась.

Журавлев Денис vasilis
Интересно, оказывается мой SQL запрос не показывал эту процедуру, потому что ее нет в sysprocauth, что не совсем нормально.

Почему это не нормально? Это для вью ненормально (когда его нет в tabauth). Или я путаю?

vasilis
Только сейчас обратил внимание на mode, который явно не стандартен.
Т.е. при создании процедуры deposit уже выл указан как владелец процедуры, но создавал ее кто то другой.

А как при dbimport от dba будет? Тоже и будет, один пользователь создаст процедуры с другим owner.

Проблема мне кажется именно в криворукости индусов и в том что имя является подстрокой владельца, попробовать повторить тоже самое, посмотреть на вывод
/* skip */

В другой таблице много таких процедур "deposit".depo_дальше_чего_то_там.
Но только именно эта процедура так себя ведет.
Я программерам предложил переименовть эту процедуру.
Когда сделают - проверю. А пока - видимо только теоретизировать можно.