Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: 1SQLITE версий 1023, 1024, 1026 и НЕ совместимость sqlite таблиц (не работает)

v7: 1SQLITE версий 1023, 1024, 1026 и НЕ совместимость sqlite таблиц (не работает)
Я
   mrJill
 
03.11.16 - 18:31
Доброго времени суток!
Имелась таблица заполненная при помощи 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.
Буду благодарен за помощь.
 
 
   Djelf
 
1 - 03.11.16 - 18:58
(0) Без понятия про sqlite studio и откуда у тебя берутся не печатные символы. Как бы так сказать... такого быть не должно!
Можно попробовать консольной версией sqlite3.exe конвертнуть...
Еще вариант ничего не конвертировать, но использовать  COLLATE _1C при обращении к базе sqlite.
Ну и можешь попробовать мои сборки 1.0.2.6 с некоторыми фиксами на более позднем движке sqlite https://cloud.mail.ru/public/9znr/ZJ6ULE9aR
   Djelf
 
2 - 03.11.16 - 19:03
+(1) Ну и или пересоздать индекс по Sklad.doc только с collate _1C, у тебя же есть индекс на это поле?
   mrJill
 
3 - 03.11.16 - 19:31
(2) сборки работают также.
А можно пример синтаксиса "COLLATE _1C", в доках читал что он добавлен, но примера не увидел (видимо плохо смотрел).

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

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

Непечатка - это, видимо, и есть те самые завершающие символы. Их studio и прихлопывает.
   mrJill
 
4 - 03.11.16 - 19:41
(1) sqlite3.exe делает то же, что и sqlite studio...

Черт меня дернул обновляться. :(
   mrJill
 
5 - 03.11.16 - 19:49
(1)
and (Sklad.doc=:ПроверДок collate _1C) - не помог. Игнорится.
   Djelf
 
6 - 03.11.16 - 21:17
(5) Спокойствие! Решим. Но у тебя что-то странное...
Ты засовываешь в базу документа в ID9, дальше сравниваешь опять таки с ID9. Collate _1С делает сравнение без учета лидирующий пробелов т.е. в принципе при сравнении на равенство тут любой вид сравнения годится.
У меня много чего подобного таким образом работает и не сбоит!
Можешь студией удалить лишнее и дать табличку на посмотреть? А то как-то не очень понятно что происходит...
Разница между 1.0.2.3 и 1.0.2.6 в принципе только в движке sqlite...
Переиндексацию делал?
   Djelf
 
7 - 03.11.16 - 21:21
(5) Надо бы проверить вот это
SELECT LENGTH(Sklad.doc) FROM Sklad GROUP BY 1

8 выводит или что то еще есть?
   Djelf
 
8 - 03.11.16 - 21:24
+() 9, конечно...
   mrJill
 
9 - 03.11.16 - 21:49
1.0.2.4
SELECT LENGTH(Sklad.doc) FROM Sklad GROUP BY 1

LENGTH(Sklad_doc);
9
21

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

Табличку - сейчас сделаю.
   Djelf
 
10 - 03.11.16 - 21:56
(9) Кажется понял на что уже пару лет ругается Ёпрст по поводу 1.0.2.6!!!
Видимо в "Подставлять" что-то сломалось, но я использую "УстановитьПараметр" в нем проблем нет.
Как раз выходные... время поработать есть ;)
 
 Рекламное место пустует
   mrJill
 
11 - 03.11.16 - 22:13
http://dropmefiles.com/dyQnW - вот табличка.

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

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

УстановитьПараметр у меня, тоже, к сожалению, не работает.
   mrJill
 
12 - 03.11.16 - 22:14
Уточнение: на 1.0.2.4 - работает, на 6 - аналогично Подставлять.
   mrJill
 
13 - 03.11.16 - 22:40
Проблема найдена (в теме Александра Орефкова изначально отписывался).
ОГРОМНОЕ СПАСИБО!

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

В упор типизацию не видел. Сам балбес оказался.
Завтра буду шерстить. На предмет INTEGER id'шников (видимо любые id по привычке как INTEGER заводились).
Странно что 2.3, 2.4 умудрялись корректные данные возвращать.
   Djelf
 
14 - 03.11.16 - 22:58
(13) Посмотрел табличку, да, у тебя там integer, но sqlite обычно на это наплевать - хотите текст в колонку с integer и будет вам исключение из правила.
SELECT * FROM sklad WHERE doc=' 1E4R6   '

отрабатывает корректно несмотря на integer.
   mrJill
 
15 - 03.11.16 - 23:32
(14) с ' 1E600 ' тоже норм (у меня именно на нем сыпался)?

В 2.4 так дела и обстоят, 2.6 только с cast или конвертацией поля в char(9) взлетела...
   mrJill
 
16 - 03.11.16 - 23:37
Видимо в движке SQLite что-то поменялось.
Запрос из STUDIO при INTEGER тоже список возвращает ( ' 1E600 ').
   Злопчинский
 
17 - 03.11.16 - 23:47
Читаю
   Djelf
 
18 - 04.11.16 - 00:06
(15) Если с каст`ом влетело, то да...
   Djelf
 
19 - 04.11.16 - 00:08
Отсутствие типизации, не верная типизация и типизация при преобразовании это все чревато последствиями...
   mrJill
 
20 - 04.11.16 - 10:01
(19) понятно. Это естественно. Сам балбес.

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

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

+ еще и данные не корректные возвращает не всегда и не везде это можно заметить сразу.
   Djelf
 
21 - 04.11.16 - 15:53
(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. У меня база после этого открылась.
   mrJill
 
22 - 04.11.16 - 16:19
(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 переходить пока побаиваюсь (вдруг не везде обнаружил, а есть обработки, не корректная работа которых критична для фин. благополучия конторы).

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

Еще раз спасибо!
   Djelf
 
23 - 04.11.16 - 19:28
Нашел! Вот в чем разница в движках 1.0.2.4 и 1.0.2.6
В sqlite была расширена поддержка форматов чисел http://www.sqlite.org/src/info/ca154f97a5907455
Т.е. " 1E4RS   " как было так и осталось строкой, а " 1E702   " из-за явного указания типизации integer стало числом, но 10 в 702 степени sqlite не поддерживает и запрос перестает работать.
   Злопчинский
 
24 - 04.11.16 - 20:05
(23)  вот оно что, Михалыч!
А если вместо Е будетD - не посчитает ли что это число двойной точности7
   Djelf
 
25 - 04.11.16 - 20:41
(24) Нет ;) SQL error: unrecognized token: "1D7"
   Злопчинский
 
26 - 04.11.16 - 23:29
(25) то есть как число не поняла?
   orefkov
 
27 - 04.11.16 - 23:57
(14)
На типизацию поля sqlite наплевать при вставке - позволит вставить хоть что хоть куда. Но не наплевать при сравнении - будет влиять на выбор, как сравнивать поля.
   Djelf
 
28 - 05.11.16 - 00:09
(27) смотри (23), (14) этого не учитывало, поскольку еще не знало ;)
   mrJill
 
29 - 06.11.16 - 15:59
(23) потрясно! :)

И ладно бы оно просто сравнить не могло, да ругнулось, оно ж радостно сообщает: вот куча значений с вашим where.
   orefkov
 
30 - 06.11.16 - 18:26
(29)
Об это многие спотыкаются. Поначалу, узнав что sqlite позволяет вставить значение любого типа в любую колонку, вдохновенно начинают забивать на типизацию, пока не напорются на подобные грабли. Я сам чрез это прошел в своё время :)
   Djelf
 
31 - 06.11.16 - 20:33
(29)(30) Я согласен с обоими мнениями, но с оговоркой.
Было бы совсем не плохо, если бы при явном указании типизации sqlite бы ругалось, а при отсутствии явной типизации кушало что дают (для варианта работы ключ-значение).

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует