Чудеса с кассовым методом (iScala 2.2, PL)

Встречался ли кто-нибудь с такой странной проблемой:

iScala 2.2 HF 2187, Книга Закупок. Кассовый метод включен в параметрах модуля. Один и тот же поставщик.

При вводе инвойсов НДС пишется на контрольный счет всегда. А вот при полной оплате НДС иногда списывается на «боевой» счет, а иногда нет…

Пробовал воспроизвести. Несколько раз вводил в тестовой компании одинаковые инвойсы и платежи; различие было только в номерах. Действительно, из 5 пар инвойс-платеж в одной не сработал перенос НДС. Изучил все related таблицы. Записи идентичны (за исключением номеров)… Трассировка запросов к базе, выполняемых Скалой, ничего интересного не дает; видать, все дело в программной логике. Есть ощущение, что проявление ошибки как-то связано с номером инвойса.

Кстати, по отзывам пользователей, в Книге Продаж то же самое творится.

Вот такая вот ботва. Может, кто-нибудь уже с этим боролся?

Путь решения:

1. Трассировал запросы к базе, которые Скала отправляет в процессе закрытия инвойса

2. Обнаружил интересный запрос такого вида:

SELECT PL17001, PL17002, PL17003, PL17004,PL17008,PL17009,PL17010,PL17017,PL17018
FROM PL17сс00

where
PL17001 = N’15 ‘ —!!! ВНИМАНИЕ!
AND
PL17002 = N’20485 ‘ —!!! ВНИМАНИЕ!
AND PL17003 = N’X’
ORDER BY PL17001,PL17002,PL17003,PL17004

Смысл понятен. Ищем, была ли запись типа X (то есть регистрация НДС по кассовому методу при вводе инвойса) и, если была, то «перекидываем» НДС при оплате, а если нет, то не «перекидываем».

Так вот, обратите внимание на пробелы, которые скала зачем-то добивает после номера инвойса и кода поставщика. В определенных случаях такой запрос РАБОТАЕТ НЕПРАВИЛЬНО. То есть не выдает ничего, хотя такая запись (без пробелов, конечно) в таблице есть. Согласно спецификации ANSI-92 SQL и Microsoft T-SQL, пробелы в конце литерала в операторах WHERE со знаком равенства не должны влиять на результат запроса. Однако влияют…

Просходит это тогда, когда в таблице есть еще одна запись, например, с PL17001=’15А’ (А—русское, aav был прав про русские буквы!). Все, при этом SQL сервер впадает в ступор и не находит запись с PL17001=’15’ по критерию PL17001=’15 ‘ (с пробелом). Причем это происходит только при поиске по нескольким полям составного ключа.

КАК ЛЕЧИТЬ

Радикальным хирургическим методом. Сменой Collation для базы данных… У нас было Cyrillic_General_BIN. Я поменял collation для PL17cc00 на Cyrillic_General_CS_AI, и запрос заработал. Так что теперь предвкушаю замену Collation для трех баз по 3-5 гигабайт…

Спасибо всем за советы. Если нужна любая дополнительная информация, обращайтесь!

YNi

Подтверждаю: влияют. iScala 2.2 SR1 на MS SQL Server 2000 SP4. Нежданно-негаданно без всяких видимых причин перестают работать отчеты по покупателю (сальдовые ведомости КП). Исследование показывает, что запрос
SELECT * FROM SL030100 WHERE SL03001 = ‘0337’
выдает строки покупателя, а запрос
SELECT * FROM SL030100 WHERE SL03001 = ‘0337 ‘
не выдает строк вообще.
Умудренный опытом работы с большими таблицами в CRM-системе коллега посоветовал убрать кластерность с первичного ключа таблицы SL03 (он наелся уже кластерности при применении BETWEEN и вставке записей в таблицы с миллионами строк). Знаете, помогло на раз, и Collation трогать не пришлось. Конечно, в своем запросе можно и явно Collation указать, тогда запрос заработает, но iScala как-то к этому факту равнодушна и формирует запросы как считает нужным.
Коллеги, пока могу только рекомендовать от CLUSTERED по возможности отказываться.

ALTER TABLE #chars ALTER COLUMN CharChar nchar(2) COLLATE Cyrillic_General_BIN NOT NULL
GO
ALTER TABLE #chars ALTER COLUMN CharBin binary(2) NOT NULL
GO

update #chars set CharChar = CHAR(CharCode) + SPACE(1) /* NOT NCHAR(CharCode) */

ALTER TABLE #chars ADD CONSTRAINT prkey PRIMARY KEY CLUSTERED (CharChar, CharBin)

update #chars set CharBin = convert(binary(2), CharChar)

dbcc dbreindex (‘#chars’)

select * from #chars order by CharCode

select *, convert(nchar(2), CharBin) from #chars order by CharBin

drop table #chars
GO
Посмотрели? Тогда на примере ряда непохожих по начертанию русских и латинских букв еще один запросик:
select Char1 COLLATE Cyrillic_General_BIN, convert(varbinary, Char1)
from (
select convert(nchar(10), N’щ’) as Char1 union
select convert(nchar(10), N’ъ’) as Char1 union
select convert(nchar(10), N’Щ’) as Char1 union
select convert(nchar(10), N’Ъ’) as Char1 union
select convert(nchar(10), N’i’) as Char1 union
select convert(nchar(10), N’j’) as Char1 union
select convert(nchar(10), N’I’) as Char1 union
select convert(nchar(10), N’J’) as Char1 union
select convert(nchar(10), N’iщ’) as Char1 union
select convert(nchar(10), N’iъ’) as Char1 union
select convert(nchar(10), N’iЩ’) as Char1 union
select convert(nchar(10), N’iЪ’) as Char1 union
select convert(nchar(10), N’iI’) as Char1 union
select convert(nchar(10), N’iJ’) as Char1 union
select convert(nchar(10), N’ii’) as Char1 union
select convert(nchar(10), N’ij’) as Char1
) chars
order by Char1 COLLATE Cyrillic_General_BIN
Вообще, как я обнаружил, тема неожиданных результатов запросов время от времени обсуждается, например, на сайте sql.ru:
http://www.sql.ru/forum/actualthread.aspx?tid=146049&hl=cyrillic_general_bin
http://www.sql.ru/forum/actualthread.aspx?tid=190274&hl=cyrillic_general_bin
http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=102413&hl=cyrillic_general_bin