Имеется такое вот чудо ... мысли.

CREATE PROCEDURE ЖурналДвижений (@КодФирмы int =4)as
begin
declare @ЖурналРасходов table (КодДвижения int , КодПрихода int , ОстатокПрихода decimal (9, 3) , КоличествоРасхода decimal (9, 3) , ФлагПартии bit )
declare @КодДвижения int , @КоличествоРасхода decimal (9, 3) , @ФлагПартии bit
declare ПереченьРасходов CURSOR FOR
select КодДвижения, КоличествоРасхода=Количество, ФлагПартии
from dbo.ДвиженияПоКорреспонденту(null, @КодФирмы, null, null)
where ТипДвижения<>'Приход'
open ПереченьРасходов
WHILE @@FETCH_STATUS = 0
begin
fetch next from ПереченьРасходов
into @КодДвижения , @КоличествоРасхода , @ФлагПартии
insert into @ЖурналРасходов
select * from dbo.СписаниеFIFOРасходы(@КодДвижения)
end
select * from @ЖурналРасходов
end

Общий смысл в том, что на каждую запись во входном наборе данных функцией СписаниеFIFOРасходы() возвращаеся несколько записей. Обе, использующиеся UDF работают как часы (китайские само собой ).
И я не буду спрашивать почему оно не работает, потому что оно работает и очень хорошо...
Но только один раз.
Т.е на Open или Debug в QA возвращается нормальный набор записей. А
exec ЖурналДвижений default первый раз отрабатывает нормально, а потом возвращает пустой набор .
На клиенте (MSAccess2000 adp) - аналогично.
Такие дела. Может кто чего знает?
P.S. Кириллица используется по настоянию клиента. Да и раньше особых проблем не было.
P.P.S. Тестовый набор в размере 2-х таблиц, двух UDF и сего творения (всего 100kb в архиве) готов сбросить по e-mail любому.
Помогите кто может!!!

Во-первых: Большое спасибо всем откликнувшимся.
Во-вторых:
2Genady:
close ПереченьРасходов
deallocate ПереченьРасходов в процедуре само собой были. Это я сократил для читабельности. Видимо напрасно.
В случае незакрытия и неубиения курсора сервер аккуратно выдает сообщение об ошибке. Так что проблема не в этом.
2SergSuper: Теоретически с Вами согласен. Практически, если курсор не пустой, все должно работать. Впрочем Ваш вариант работает точно также т.е. - один раз. Так что проблема и не в этом тоже.
2GreenSunrise and ALL:
>А вот если молча возвращает пустой набор записей, то дело, скорее всего, не в этом.
Дело судя по всему действительно не в этом. Ошибка начала возникать после переустановки сервера и не только в этой процедуре, а во всех процедурах, использующих в теле вызовы UDF . В том числе в тех, которые написаны в точном соответствии с советом SergSuper.
А особая мистика в том, что вновь созданная процедура, дословно повторяющая старую работает нормально. Такие дела.
Судя по всему дело в каких-то установках сервера.
Может у кого есть идеи в каких? А то чего то пересоздавать все SP не очень хочется.
Как все-таки получается, что на Open и Debug в QA одна и та же SP отрабатывет нормально, а на exec начинает фокусничать?
Сталкивался ли кто-либо с подобными вещами, и как боролся?
Еще раз спасибо Всем.
А я продолжу пока эксперимент .

Всем большое спасибо.
Главное заинтересовать общественность и уехать в командировку .
После неоднократных перустановок сервера и перекомпиляции процедур все заработало. Почему заработало определить не удалось. Воспроизвести ошибку на другом сервере не удалось так же. Жаль. Ну да ладно.
Подкину еще один интересный момент, имеющий отношение, как к выбору между переменными типа table и временными таблицами, так и к мистике, исполняемой иногда сервером. Итак:

CREATE procedure Numbers_p (@n bigint = 100000)
as
begin
declare @m bigint
declare @Table table (i bigint , k bigint)
set @m=0
while @m<@n
begin
set @m=@m+1
insert into @Table values (@m , @m)
end
select * from @Table
end

или так:

CREATE procedure Numbers_vr (@n bigint = 100000)
as
begin
declare @m bigint
create table #Table (i bigint , k bigint)
set @m=0
while @m<@n
begin
set @m=@m+1
insert into #Table values (@m , @m)
end
select * from #Table
end

Во первых работает быстрее на разных машинах то первый вариант, то второй (от чего зависит так и не понял). Но чаще первый быстрее (в среднем на 20-30%), оно и понятно, если памяти хватает, то таблицы-переменные по идее должны работать быстрее. А вот если оперетивки не хватает, да процессор слабый, да файл подкачки маловат и увеличивается по ходу выполнения процедуры, то запросто можно получить 100 000 записей, последняя из которых будет не 100000, 100000 , а например 99992, 99992. Я неоднократно воспроизводил подобное у клиентов на "серверах" типа Celeron 366, 64 MB, особенно если минимальный размер файла подкачки не увеличить заранее. Можно конечно иронизировать по поводу конфигурации машины. Но во-первых, чего еще нужно на рабочую группу из 5 пользователей? Во-вторых, если серверу не хватает ресурсов, IMHO, он должен об этом сообщить, а не выдавать после 4 минут работы неверный результат. Или может я чего неверно понимаю? Главное не понятно, как бороться с подобными вещами.