До недавнего времени база 1с массой в 2 гига крутилась на SQL2005 Win2k3 32 бита. В один прекрасный момент на указанном сервере разъехался RAID. Благо к тому времени уже был почти установлен новый сервер, но с Win2008 R2 х64. Все копии были вовремя сняты и развернуты на новом сервере. Т.е. простоя почти не было.
Самое интересное выяснилось позже: на SQL2005 64 не отрабатывают хранимые процедуры. Т.е. запросы, создаваемые через хранимые процедуры возвращают пустой результат.
Обращение к SQL происходит посредством Rainbow.dll
В создании запросов к SQL я только начинаю разбираться,

"Обращение к SQL происходит посредством Rainbow.dll"

Скажите, а свою лошадь перед выездом за деревню чем вы кормите? Овсом или сеном?

я так понимаю, сами хранимые процедуры что-то возвращают?

(1) Да супом они кормят. Супом. Вот только там одна юшка и лошадь су** нехочет ехать. И за 6 лет ненаучиться элементарному тоже нужно уметь.

(1) отмачиваю ее в керосине.
конфигурация написана из ТиС 8.какого-то за последние 10 лет практически до неузнаваемости. И в каком виде она мне досталась 2 недели назад, в таком я ее пока и оставлю.
Если есть что сказать, приму к сведению.
(2) По идее должны возвращать остаток товара на складе. Как посмотреть коды ошибок, я пока не знаю. Rainbow той версии, что у нас, их не показывает.

на самом сервере возвращают ли данные хранимые процедуры? не через 1С!

при восстановлении базы на 32-битном серваке помогает. Но у меня он стоит локально, и для рабочей базы не пойдет.
(5) сейчас посмотрю

Ты нам лучше покажи что товарищ профайлер показывает при потугах вывести нужное. А потом уже загадки гадать.

кажется разобрался. Похоже ему не нравится формат даты
Msg 242, Level 16, State 3, Procedure GdeTovarLesgit, Line 43
The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.
Дата передается в виде '30.05.2012'

Значит кодовую страницу в скуле неправильно выставил.

а какой он должен быть для х64? Кстати, вполне возможно он берет формат из системы. Сейчас посмотрю.

(8) такую дату и sql200 не поймет.
приведи текст хп.
Может у тебя на разных серверах разные хранимые процедуры ?

нет, наврал, формат даты - '30.05.12'

сама процедура:

set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[GdeTovarLesgit] (@DatBeg Char(8),@Tovar VarChar(MAX),@Mesto VarChar(MAX))
AS
DECLARE @Tab1 Table (Tovar Char(9), Ost Float)
DECLARE @Tab2 Table (Mesto Char(9))
DECLARE @Flag1 Bit
DECLARE @idoc integer
DECLARE @Tab3 Table (Tovar Char(9), Mesto Char(9), Reserv Numeric(16,2), Ostatok Numeric(16,2), Partiy Char(9))
DECLARE @Tab4 Table (Tovar Char(9), Mesto Char(9), Reserv Numeric(16,2), Ostatok Numeric(16,2), Partiy Char(9))        
DECLARE Pusto Char(9)
SET NOCOUNT ON    
SET Pusto='     0   '                

/* Список конкретного товару */
IF @Tovar is Null
  SET @Flag1 = 0
ELSE
BEGIN
  SET @Tovar='<root><x val='+replace(@Tovar,',','/><x val=')+'/></root>'
  EXEC sp_XML_preparedocument @idoc OUTPUT, @Tovar
  INSERT INTO @Tab1 (Tovar) SELECT RIGHT('      '+RTRIM(LTRIM(Val))+'   ',9) FROM OPENXML(@idoc,'/root/x',1)
  WITH (val CHAR(9))
  EXEC sp_XML_removedocument @idoc
  SET @Flag1 = 1
END                  

/* Список конкретных мест , вернее берется товар из списка конкретных мест */
IF @Mesto is not Null
BEGIN
  SET @Mesto='<root><x val='+replace(@Mesto,',','/><x val=')+'/></root>'
  EXEC sp_XML_preparedocument @idoc OUTPUT, @Mesto
  INSERT INTO @Tab2 (Mesto) SELECT RIGHT('      '+RTRIM(LTRIM(Val))+'   ',9) FROM OPENXML(@idoc,'/root/x',1)
  WITH (val CHAR(9))
  EXEC sp_XML_removedocument @idoc
  INSERT INTO @Tab1 (Tovar, Ost) SELECT S.SP3769,SUM(S.SP3770) FROM RG3759 S WHERE S.Period=Convert(datetime,@DatBeg)
       and (S.SP3762 in (SELECT Mesto From @Tab2)) GROUP BY S.SP3769,S.SP3762 HAVING SUM(S.SP3770)<>0
  SET @Flag1 = 1        
END    

/* Товар, Место,Резерв,Остаток=0 */
INSERT INTO @Tab3 (Tovar,Mesto, Reserv, Ostatok,Partiy)
SELECT R.SP4518,R.SP4517,SUM(R.SP4523),0,R.SP4521 FROM RG4516 R WHERE R.Period=Convert(datetime,@DatBeg)
   and (R.SP4517<>Pusto)
   and (((@Flag1=1) and (R.SP4518 in (SELECT Tovar From @Tab1))) or (@Flag1=0))
    GROUP BY R.SP4518,R.SP4517,R.SP4521
UPDATE @Tab3 SET Reserv=0 Where Reserv is Null
/* Товар, Место, Резерв=0, Остаток */
INSERT INTO @Tab3 (Tovar,Mesto,Reserv,Ostatok,Partiy)
SELECT S.SP3769,S.SP3762,0,SUM(S.SP3770),S.SP4057 FROM RG3759 S WHERE S.Period=Convert(datetime,@DatBeg)
   and (((@Flag1=1) and (S.SP3769 in (SELECT Tovar From @Tab1))) or (@Flag1=0))
       GROUP BY S.SP3769,S.SP3762,S.SP4057

UPDATE @Tab3 SET Ostatok=0 Where Ostatok is Null

INSERT INTO @Tab4 (Tovar,Mesto,Reserv,Ostatok,Partiy)
SELECT Tovar,Mesto,SUM(Reserv),SUM(Ostatok),Partiy FROM @Tab3 GROUP BY Tovar,Mesto,Partiy
/* Все что Остаток не равен нулю */
SET NOCOUNT OFF
SELECT Tovar,Mesto,Reserv,Ostatok,Partiy FROM @Tab4 WHERE Ostatok<>0

(10) Cyrillic_general_CI_AS
И для скуля и для базы. Плюс файлик OrdNoChk.prm в каталог базы 1С.

GdeTovarLesgit - улыбнуло.
Хорошо еще, что не Gde_Blyad_Tovar

процедура отрабатывает, но выводит пустой результат.
Данные есть. Инфа 110%

(14) думаешь если процедуру переименовать, покажет что-нить?

(13) все это есть

(15) Значит, отлаживай процедуру.

А так
Вместо

Convert(datetime,@DatBeg)

Написать

Convert(datetime,@DatBeg,2)

Но он по идее и в 2000 не должон был работать, там по умолчанию третий параметр 0.

(19)+ Это для даты в строке с годом без столетий.

(19)+ А не прогнал. Там другой формат для 2.

>>>нет, наврал, формат даты - '30.05.12'

это монопенисуально в данном случае.
:)

(22) но тем не менее из 1с дата передается в таком виде, и ошибок не возникает. В большинстве случаев. Вот только в случае 64 бит результат пуст.

а сказано красиво :)

(24) Посмотри, какие аргументы передаются, и отлаживай в КвА с такими же аргументами....

(23) и это не верно, надо как минимум строкой 20120121

в общем действительно, поправил в параметрах функции Convert(). После этого результаты появились.
Сделал Convert(datetime,@DatBeg,4)