Eprst писал(а) 31. Октября 2014 :: 10:19:Ошибка была другая. 26 валился ну на совсем примитивных запросах. Просто форум поломался и половины сообщений потерялись, в том числе, в ветке про 1sqlite
+Были ошибки с граничными значениями в запросе
Это очень печально, что все потерялось... Погуглил по сабжу, но нашел только сообщения такого вида "Eprst > 1.0.2.6 глючная"
Судя по изменениям в 1sqlite 1.0.2.3 от 1.0.2.5 не сильно отличаюся (1.0.2.4 нету в svn, а репозитарий на fosill сдох), кроме замены движка sqlite т.е. виноват был все таки он.
alyuev писал(а) 31. Октября 2014 :: 11:42:Интересно, а на старой версии 1.0.2.4 этот финт
cast(code as float)
не проходит - не ругается, но возвращает неверное значение для длинных чисел. За решение - Спасибо!
Так и должно быть. Передача таких чисел между 1sqlite и sqlite была добавлена в неопубликованной версии 1.0.2.5
Проверил несколько движков sqlite 3.8.*, пошаманил с оптимизатором, все равно получается какая то ерунда, я ему вес 1 даю на индекс по Документ_Строки, а он все равно выберает сырое чтение... На одном моем запросе падение скорости в 100500 раз. Где косяк спрятался не очень пока понятно.
Ну да ладно, обновил движок sqlite до 3.7.17.0 (последний где оптимизатор не глючит).
Забавно, постенький запрос стал раза в полтора быстрее.
SELECT
РегПар.Номенклатура [Номенклатура $Справочник.Номенклатура],
sum(case DEBKRED when 1 then 0 else РегПар.Количество end) [КоличествоПриход $Число.15.5],
sum(case DEBKRED when 1 then РегПар.Количество else 0 end) [КоличествоРасход $Число.15.5]
FROM Регистр_ПартииНаличие AS РегПар
WHERE РегПар.date BETWEEN :НачДата AND :КонДата
GROUP BY РегПар.Номенклатура
на более сложных запросах +10-15%
+ заработала оптимизация по IN (запросы на выбор индекса стали поступать в 1sqlite).
- оптимизация по IN может быть не адекватно обработана планировщиком sqlite
http://www.1cpp.ru/forum/YaBB.pl?num=1418818749/6#6