Доброго времени суток!
Имелась таблица заполненная при помощи 1sqlite 1.0.2.3 следующим образом:

ЗапросSQLite.Подставлять("ТекВремя",ТекущееВремя());
ЗапросSQLite.Подставлять("ТекДата",ТекущаяДата());
ЗапросSQLite.Подставлять("ТекДок",Док);
            
ТекстЗапроса="
|INSERT INTO Sklad (time, date, given, doc) VALUES (:ТекВремя,:ТекДата,0,:ТекДок);
|";

Запрос к таблицам базы работал корректо. Текст запроса:

ЗапросSQLite.Подставлять("НачДатаПров",ТекущаяДата()-45);
ЗапросSQLite.Подставлять("КонДатаПров",ТекущаяДата());
ЗапросSQLite.Подставлять("ПроверДок",Док);

ТекстЗапросаПров="
|SELECT
|    Sklad.doc as [Реализация $Документ.Реализация]
|FROM
|    Sklad
|WHERE
|    (Sklad.date between :НачДатаПров and :КонДатаПров)
|    and (Sklad.doc=:ПроверДок)
|";

После обновления на версию 1.0.2.6 запрос перестал выполнять условие: "(Sklad.doc=:ПроверДок)"

Вернуться на 1.0.2.3 пока не удалось: "file is encrypted or is not a database".

Перешел на 1.0.2.4, но после использования 1.0.2.6 тормоза ЛЮТЫЕ.

Что характерно:
"
|SELECT
|    Sklad.doc as [Реализация $Документ.Реализация]
|FROM
|    Sklad
|WHERE
|    (Sklad.date between :НачДатаПров and :КонДатаПров)
//|    and (Sklad.doc=:ПроверДок)
|    and (Sklad.doc LIKE '%'||:ПроверДок||'%')
" - работает.

Конвертация таблиц при помощи sqlite studio убивает непечатные символы, которые 1с инсертит в таблицы, соответственно обработки работать прекращают.

Пока пытаюсь изобразить на 1.0.2.4 обработку пересоздания и перезаполнения (полагаю, что пересоздав базу в текущей sqlite тормоза уйдут), но хотелось бы и иных более вменяемых предложений.

Более всего надеюсь на помощь от разаработчика 1.0.2.6.
Буду благодарен за помощь.

(0) Без понятия про sqlite studio и откуда у тебя берутся не печатные символы. Как бы так сказать... такого быть не должно!
Можно попробовать консольной версией sqlite3.exe конвертнуть...
Еще вариант ничего не конвертировать, но использовать  COLLATE _1C при обращении к базе sqlite.
Ну и можешь попробовать мои сборки 1.0.2.6 с некоторыми фиксами на более позднем движке sqlite https://cloud.mail.ru/public/9znr/ZJ6ULE9aR

+(1) Ну и или пересоздать индекс по Sklad.doc только с collate _1C, у тебя же есть индекс на это поле?

(2) сборки работают также.
А можно пример синтаксиса "COLLATE _1C", в доках читал что он добавлен, но примера не увидел (видимо плохо смотрел).

COLLATE _1C пользовать, конечно решение, но обработок с табличками SQLite работающих много и легко что-нибудь прохлопать...

Сейчас попробою sqlite3.exe

Непечатка - это, видимо, и есть те самые завершающие символы. Их studio и прихлопывает.

(1) sqlite3.exe делает то же, что и sqlite studio...

Черт меня дернул обновляться. :(

(1)
and (Sklad.doc=:ПроверДок collate _1C) - не помог. Игнорится.

(5) Спокойствие! Решим. Но у тебя что-то странное...
Ты засовываешь в базу документа в ID9, дальше сравниваешь опять таки с ID9. Collate _1С делает сравнение без учета лидирующий пробелов т.е. в принципе при сравнении на равенство тут любой вид сравнения годится.
У меня много чего подобного таким образом работает и не сбоит!
Можешь студией удалить лишнее и дать табличку на посмотреть? А то как-то не очень понятно что происходит...
Разница между 1.0.2.3 и 1.0.2.6 в принципе только в движке sqlite...
Переиндексацию делал?

(5) Надо бы проверить вот это
SELECT LENGTH(Sklad.doc) FROM Sklad GROUP BY 1
8 выводит или что то еще есть?

+() 9, конечно...

1.0.2.4
SELECT LENGTH(Sklad.doc) FROM Sklad GROUP BY 1

LENGTH(Sklad_doc);
9
21

Нашел мусорную строку - грохнул.
LENGTH(Sklad_doc);
9

Табличку - сейчас сделаю.

(9) Кажется понял на что уже пару лет ругается Ёпрст по поводу 1.0.2.6!!!
Видимо в "Подставлять" что-то сломалось, но я использую "УстановитьПараметр" в нем проблем нет.
Как раз выходные... время поработать есть ;)

http://dropmefiles.com/dyQnW - вот табличка.

Тоже видел что ругается, но уже после того как обновился.

Выходные - да. Время отвлечься от шумных буден и насладиться щелканьем своих клавиш в тихом офисе.
Знаем. Практикуем. Планируем на завтра.

УстановитьПараметр у меня, тоже, к сожалению, не работает.

Уточнение: на 1.0.2.4 - работает, на 6 - аналогично Подставлять.

Проблема найдена (в теме Александра Орефкова изначально отписывался).
ОГРОМНОЕ СПАСИБО!

Александр заметил, что типизация doc - INTEGER.

В упор типизацию не видел. Сам балбес оказался.
Завтра буду шерстить. На предмет INTEGER id'шников (видимо любые id по привычке как INTEGER заводились).
Странно что 2.3, 2.4 умудрялись корректные данные возвращать.

(13) Посмотрел табличку, да, у тебя там integer, но sqlite обычно на это наплевать - хотите текст в колонку с integer и будет вам исключение из правила.
SELECT * FROM sklad WHERE doc=' 1E4R6   '
отрабатывает корректно несмотря на integer.

(14) с ' 1E600 ' тоже норм (у меня именно на нем сыпался)?

В 2.4 так дела и обстоят, 2.6 только с cast или конвертацией поля в char(9) взлетела...

Видимо в движке SQLite что-то поменялось.
Запрос из STUDIO при INTEGER тоже список возвращает ( ' 1E600 ').

Читаю

(15) Если с каст`ом влетело, то да...

Отсутствие типизации, не верная типизация и типизация при преобразовании это все чревато последствиями...

(19) понятно. Это естественно. Сам балбес.

Но когда sqlite оно молчаливо хавал и возвращал корректные данные, а потом эту "фичу" выпилили и вернуться на предыдущую версию без проблем возможности нет - это... становится серьезной неожиданностью.

У меня, н-р в различных системах автоотправки/автозагрузки/автопечати и системах обмена таких табличек не один десяток... Перешерстить теперь не мало нужно.

+ еще и данные не корректные возвращает не всегда и не везде это можно заметить сразу.

(20) Если ты про оригинальную 1.0.2.6 то она может так себя вести. Ну вот например http://www.sqlite.org/src/info/b7c8682cc1 Но с тех пор движок sqlite поменялся очень сильно.
Сверил код 1sqlite, как и предполагал, ломающих изменений не нашел.
Чтобы база открылась на 1.0.2.3 нужно хекс-редактором в заголовке поправить байтики по адресу 0х12 и 0х13 с 0х02 на 0х01. У меня база после этого открылась.

(21) За байтики - большое спасибо. Буду знать.
Это бы теперь куда-нить в описание: вдруг кто откатиться надумает.

Вопрос здесь не к 1sqlite, а именно к sqlite движку.
Фигакс и часть полей char(9) с integer (того же length) уже корректно не сравнить. Хошь бы ошибки какие писали при запросах/инсертах.

Останусь пока на 1.0.2.4 (тормоза были в некоторых таблицах из-за join'ов без индексов), 1.0.2.3 - такие моменты без тормозов отрабатывала (видимо где-то иная логика подбора индекса 1с таблиц была). Добавил в sqlite базы индексы - завертелось.
Типизацию, естественно, поправил везде, где обнаружил (теперь на всю жизнь запомню что id и integer очень чревато ассоциировать и при работе с 1с нужно почаще смотреть в dd'шник), но на 1.0.2.6 переходить пока побаиваюсь (вдруг не везде обнаружил, а есть обработки, не корректная работа которых критична для фин. благополучия конторы).

В общем приключение создал себе (да и другим) с не тривиальным сюжетом, немного пугающее, но, похоже, близящимся хэппи эндом.

Еще раз спасибо!

Нашел! Вот в чем разница в движках 1.0.2.4 и 1.0.2.6
В sqlite была расширена поддержка форматов чисел http://www.sqlite.org/src/info/ca154f97a5907455
Т.е. " 1E4RS   " как было так и осталось строкой, а " 1E702   " из-за явного указания типизации integer стало числом, но 10 в 702 степени sqlite не поддерживает и запрос перестает работать.

(23)  вот оно что, Михалыч!
А если вместо Е будетD - не посчитает ли что это число двойной точности7

(24) Нет ;) SQL error: unrecognized token: "1D7"

(25) то есть как число не поняла?

(14)
На типизацию поля sqlite наплевать при вставке - позволит вставить хоть что хоть куда. Но не наплевать при сравнении - будет влиять на выбор, как сравнивать поля.

(27) смотри (23), (14) этого не учитывало, поскольку еще не знало ;)

(23) потрясно! :)

И ладно бы оно просто сравнить не могло, да ругнулось, оно ж радостно сообщает: вот куча значений с вашим where.

(29)
Об это многие спотыкаются. Поначалу, узнав что sqlite позволяет вставить значение любого типа в любую колонку, вдохновенно начинают забивать на типизацию, пока не напорются на подобные грабли. Я сам чрез это прошел в своё время :)

(29)(30) Я согласен с обоими мнениями, но с оговоркой.
Было бы совсем не плохо, если бы при явном указании типизации sqlite бы ругалось, а при отсутствии явной типизации кушало что дают (для варианта работы ключ-значение).

Если посмотреть по моей ссылке в (23) на тикет, то это преобразование было сломано в sqlite >3.1.3 и починено в >3.7.2 т.е. за 5 лет никто не обнаружил!
Ну вот прошло еще почти 5 лет со времени 3.7.3 и эта ошибка опять вылезла, только наоборот ;)
Сейчас этот случай есть в тестах и больше не пройдет, но при авто-контроле явной типизации не продержался бы и неделю.

С другой стороны понятно почему этого нет. Этот движок sql разрабатывается как встраиваемый с экстримально компактным  размером, поэтому перегружать ее встроенными возможностями Hipp видимо он не хочет.
P.S. но мог бы сделать опцией при компиляции и прагмой... эх...