Ну, у меня в одной колонке Period=INTEGER, а в другой Next=INTEGER. Обычная сумма плюс корректор выдаст нормальную следующую дату
------------ Дoбавленo в 16.44:
Да, напомни, если несложно, как правильно работать с LIKE и русскими символами без доп компонентов, чисто из запроса. Обязательно ли нужно конвертить базу в UTF-8

Period в днях или в годах ?
Next - в каких единицах ?В принципе - да.

В днях

INTEGER, наша обрезанная дата, правда, там нужен Previouse предыдущее поле

Вроде сожрало обычную сумму, но точно ли отсчитало, ХЗ, считать надо.

Вот этот кусок
Это тренировочный вариант, в Next будет записана потом откорректированная вручную дата

Лучше в UTF-8. Тогда и колонки можно по русски назвать и LIKE вроде нормально работает. (на иврите - точно.)

А с pragma что-то мудрить надо, или по дефолту покатит
------------ Дoбавленo в 17.01:

Нафиг, лучше на оригинале, привычнее

Использую для создания БД SQLite Expert Personal 3

А я по-деревенски -- Sqliteadmin. Правда, у него есть недокументированные глюки, но мне удалось их обойти. К примеру, при создании целочисленного поля, он категорически отказывался в него что-то писать до полного перезапуска базы
------------ Дoбавленo в 10.07:
Tad, при базе в UTF-8, LIKE надо задавать тоже в UTF-8, или достаточно писать на языке своей локации
------------ Дoбавленo в 16.03:
Интересно, а как сделать регистронезависимый LIKE для UTF-8, у меня не получилось

Я все свои SELECT-ы прогоняю, перед подачей на SQLite_Query (DSC_Query), через CharSet. не пробовал.
А PRAGMA case_sensitive_like = boolean;
Не помогает?

Редактировалось 2 раз(а), последний 2021-05-21 12:28:13

37.45.101.18, лично !
code_29229.txt
Можно ВСЁ.

Нет, она помогает только на ASCII (к тому же, по дефолту она выключена), а UTF-8 другого регистра отличается от смещений ASCII
------------ Дoбавленo в 23.13:

Вот и мне пришлось точно так и сделать, добило только, что нельзя осуществить поиск на любом регистре, приходится писать, соблюдаяя регистр

nesco, кстати о птичках:
Like можно задавать и так.
nesco,я не знаю, что ты творишь, но приводи к общему знаменателю перед записью в БД. Что за проблемы с регистром ?

Ну и нахрен мне в базе улицы на кириллице все с маленькой или с большой буквы.

А то, что LIKE не ищет у меня в UTF базе без учета регистра. Например -- записано Просвещение пытаюсь найти %просв% (естественно, переведя в UTF-8) -- фиг, пока не поставлю %Просв%, тогда находит.

Такой запрос напрямую у меня не работает, только после перевода в UTF-8

Я так понял, что LIKE расчитан на поиск только в АSCII, после переаода в UTF-8, кириллица становится двухсимвольным ASCII, смею предположить, что регистронезависимого поиска, в таком случае, добиться будет нельзя

nesco, тут говорят,
что в общем случае (для произвольных UTF-8 строк) задача регистронезависимого сравнения не решаема. Для частного случая (кирилица плюс латиница) написать свою функцию сравнения. И вроде где-то на форуме выкладывался obj с такой функцией.

Забываем про существование StrCase.FirstChar. Пример подготовки данных перед записью в БД
http://forum.d2h.ru/forum.html?q=3&p=161892#p161892. То же делаем и перед поиском.
Умный человек придумал ивритское письмо - одни большие буквы и никаких маленьких.