А с "deScr" таки да работает. Видимо вшито в компоненту своё имя? Или потому что английское?

Кстати, с поиском по LIKE 'БлаБла%' - проверил версии где работало и где перестало. Последняя рабочая, которая у меня нашлась - 316214. И следующая у меня была 3_22_019. На ней уже не работает поиск.

И на последней _3_40_1_28 - тоже не работает запрос:

SELECT
 Спр.deScr
FROM Справочник_Клиенты as Спр
WHERE Спр.DESCR LIKE 'яя_ю%' 

забавно, а такой на ней же работает:

SELECT
 Спр.deScr
FROM Справочник_ЯзыкиФраз as Спр
WHERE Спр.Русск LIKE 'ТСД%' 

alyuev писал(а) 06. Июня 2023 :: 16:10:


Знак процента представляет ноль, один или несколько чисел или символов. Подчеркнутый символ представляет собой одно число или символ. Эти символы могут использоваться в комбинациях.
Для экранирования можно использовать знак ?

Напишу для памятки, в качестве заметки, как экранировать:

LIKE 'zz?_%' ESCAPE '?' 

но вместо ? можно использовать любой символ, например, \ @  и пр...

LIKE 'zz\_%' ESCAPE '\' 

И, как оказалось, включение экранирования - сделало рабочим запрос на начало строки! И сортировку меняет.

У Орефкова написано utf-16 стоит использовать "из соображений производительности". На самом деле это не так критично.
Но у него написано что и с utf-8 компонента для 8ки работает.
Не уверен что 7ка в utf-16 запишет, перекодирование из 7ки поступает в sqlite в utf-8, так наверное не сработает.
Видимо формат базы стоит оставить в uft-8.

Из 1С7 записываю данные во внешний sqlite-файл (таблицу "Контрагенты") командой "лЛокБаза.УложитьТЗ(лТЗ, "Контрагенты77", 1)".
В ТаблицеЗначений есть поля "Наименование", "ИНН".

В sqlite-базе почему-то наименования контрагентов обрезаются. Длина поля получается 22 символа.
Почему так получается? Как сделать, чтобы в базу записалось полное наименование?

И еще при записи из 1С7 в sqlite-базе вначале всех полей добавился символ "S". Откуда он берется? В 1С8 я читаю эту таблицу с помощью ADO, и все данные возвращаются с символом "S". Например, из записываю ИНН "6027057894", а он записывается как "S6027057894", и читается в 1С8 тоже как "S6027057894".
Как этого избежать?

На 3_40_1_28 не взлетел такой запрос:

SELECT
	Журнал.IDDOCDEF||Журнал.IDDOC as [Док:Документ],
	PARENTVAL,
	SubStr(PARENTVAL,7,9) as [Кл:Справочник.Клиенты],
	CASE WHEN ПН.ЗаказПоставщику=1 THEN 'Order to supplier' WHEN ПН.Оригинал=2 THEN 'Advances invoice' WHEN ПН.Оригинал=3 THEN 'Proforma Invoice' When Сч.Давальческая=1 Then 'Order GIVEN' When Сч.ТипСчета=0 Then 'Счет-Заказ' ELSE '' END as НазвИнвойса,
	CASE WHEN ПН.ЗаказПоставщику=1 THEN 1 WHEN ПН.Оригинал=2 THEN 2 WHEN ПН.Оригинал=3 THEN 3 When Сч.Давальческая=1 Then 4 When Сч.ТипСчета=0 Then 5 ELSE 0 END as ДляСорт
FROM
	__1S_CRDOC As Отбор
Inner JOIN
	Журнал on Журнал.IDDOC = Отбор.ChildID
Left JOIN
	Документ_ПриходнаяНакладная As ПН On ПН.IDDOC=Отбор.ChildID
Left JOIN
	Документ_Счет As Сч On Сч.IDDOC=Отбор.ChildID
WHERE
	(MDID=:ГрафаОтбора.КлиентПриходных Or MDID=:ГрафаОтбора.КлиентСчетов)
	AND Журнал.Date between '20220513' and '20230613'
	AND (Сч.ТипСчета=0))
	AND PARENTVAL = 'B1' || :ВидСправочника.Клиенты || :Клиент
	AND CLOSED&1=1 	-- ограничение на выбор записей только проведенных документов. Фактически при корректных записях в базе, это условие '&1' лишнее, но при каких то «глюках» таким условием можно «отловить» непроведенные документы с существующими движениями (к сожалению такое может встречаться).
ORDER BY ДляСорт, Журнал.Date 

Из плана запроса 28й версии:
SCAN Отбор VIRTUAL TABLE INDEX 1:PARENT;    13 !" 0p .!%
SCAN Журнал VIRTUAL TABLE INDEX 1:ACDATETIM;    14 !" 0
SCAN ПН VIRTUAL TABLE INDEX 0:ID;    10 !  0p nHyd!   kM LEFT-JOIN
SCAN Сч VIRTUAL TABLE INDEX 0:ID;    10 !  0p nHyd!   kM LEFT-JOIN
USE TEMP B-TREE FOR ORDER BY


На 26й версии
SCAN Отбор VIRTUAL TABLE INDEX 1:PARENT;    13 !" 0p .!%
SCAN Журнал VIRTUAL TABLE INDEX 0:IDDOC;    21 !  0p nHy$|0`
SCAN ПН VIRTUAL TABLE INDEX 0:ID;    10 !  0p nHyd!
SCAN Сч VIRTUAL TABLE INDEX 0:ID;    10 !  0p nHyd!
USE TEMP B-TREE FOR ORDER BY

alyuev писал(а) 07. Июня 2023 :: 11:40:

Ну так подави использование ACDATETIM
AND +Журнал.Date between '20220513' and '20230613'
Это не хак, это нормальный задокументированный путь.
Планировщику иногда помогать надо...