kiruha писал(а) 24. Июня 2008 :: 09:11:

В SQLite пишется

Select
...
WHERE MyIndex>'Какое то значение'
Order by MyIndex
limit N
 

если индекс есть по полю MyIndex, он используется.

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

При ключе с двумя полями входящими в один индекс, все гораздо хуже. Для MSSQL у Дмитро применяется сейчас такая конструкция:

where field1 > 'key1' or (field1 = 'key1' and field2 > 'key2')
 

MSSQL нормально понимает такую запись, двигает по индексу.
SQLite - во-первых выражения, объединенные по OR не оптимизирует, только по AND.
Во-вторых, с константами не работает (те он все равно не поймет, что в обоих подусловиях одинаковый 'key1')

Если переписать условие вот так:

where field1 >= 'key1' AND NOT (field1 = 'key1' AND field2 <='key2')
 

то SQLite для начала двинет по индексу на 'key1', потом будет идти по индексу, проверяя каждую запись на NOT (field1 = 'key1' AND field2 <='key2')
Это конечно несколько оптимальнее, но все равно не то, чего бы хотелось. А если еще и по первому полю селективность низкая, вообще хреново.
К сожалению, умение составлять английские предложения - не сильная моя черта, а то бы давно им фичереквест написал.

А такой запрос:

SELECT *
	|FROM Сотрудники
	|WHERE UPPER(Сотрудники.Descr) like 'Орефков%' 

не должен попадать в индекс Descr ?
Fox попадает.

и ещё:
1. так НЕ попадает:

WHERE UPPER(Сотрудники.Descr) = 'Орефков' 

2. так попадает:

WHERE Сотрудники.Descr = 'Орефков' 

3. так НЕ попадает

WHERE Сотрудники.Descr like 'Орефков%' 

[quote author=orefkov link=1214205575/30#42 date=1214287457]Ошибку нашел.
Исправил.
В шапке.
1.0.1.3[/quote]
гут. :)
спасибо.

А типизацию субконто а-ля ODBCRecordset сложно сделать?

[quote author=steban link=1214205575/60#67 date=1214307188][quote author=orefkov link=1214205575/30#42 date=1214287457]Ошибку нашел.
Исправил.
В шапке.
1.0.1.3[/quote]
гут. :)
спасибо.

А типизацию субконто а-ля ODBCRecordset сложно сделать?[/quote]

Как раз таки делаю. Если посмотреть исходники, видно ведь
[code]
case ttSubconto:
     break;
[/code]

orefkov писал(а) 24. Июня 2008 :: 11:54:

В таком виде, конечно нет
Но я вот сейчас и тестирую все это дело...
Самый частый вопрос - разбивка остатка на основные и базовые единицы... Коэффициент основной единицы возвращается криво очень часто, все дальнейшие расчеты с его использованием ессно тоже кривые. Т.е. для норального расчета нужно юзать ROUND.
А потом сидеть и думать - как бы где еще не попалось число, которое храниться будет неправильно. ИМХО нездорово это

Chieftain писал(а) 24. Июня 2008 :: 11:58:

Можешь показать пример на конкретных числах, где конечный результат расчета (при установке типизации колонки Число.Длина.Точность) отличается от результата Фокса или 1С ?