Отправлено: 26.02.11 14:25. Заголовок: Проблема с условной индексацией 2

Возвращаюсь к этой теме повторно !

Раньше было получено рабочее решение:
условной индексации по БД из 60 000 записей, имеющей 263 поля и занимающей 55 Мб решается так:
nKolRecords := LASTREC()
cIndexTo := "PADL(ALLTRIM(FIELD->CNumKvar),5)"
cFilterTo := "NN==2010490.AND.!DELETED()"
----------------------------------------------------------------------------------
INDEX ON &cIndexTo TAG "ONE" TO ("temp.cdx") ;
EVAL SAY_PROC() ;
EVERY nKolRecords / 10 ;
WHILE &cFilterTo ADDITIVE // замена на FOR &cFilterTo ADDITIVE увеличивает построение индекса на 6 сек.
ORDSETFOCUS( "ONE" )
DBSETORDER(INDEXORD())
DBGOTOP()

где SAY_PROC() - функция рисования бегунка, возвращает всегда .T.

Сейчас потребовалась выборка по дате:

cIndexTo := "DTOS(FIELD->DATEPRIX)+STR(FIELD->TIMEPRIX)"
cFilterTo := "DATEVvod=CTOD("26.02.11).AND.KOPERAT=101.AND.!DELETED()"
---------------------------------------------------------------------------------
INDEX ON &cIndexTo TAG "ONE" TO ("temp.cdx") ;
EVAL SAY_PROC() ;
EVERY nKolRecords / 10 ;
WHILE &cFilterTo ADDITIVE
ORDSETFOCUS( "ONE" )
DBSETORDER(INDEXORD())
DBGOTOP()

Индекс строится мгновенно, но функция FOUND() всегда возвращает .F. - хотя если поставить заместо WHILE ---> FOR то нормально работает, правильно возвращает.
но FOR - строит медленнее... чем WHILE .....

В чем дело, тип ДАТА или ЧИСЛА неправильно в фильтре ??? или еще чего ??? подскажите пожалуйста.

 Отправлено: 24.03.11 20:17. Заголовок: Попробуй запросы ADS..

Попробуй запросы ADS. База у тебя не такая уж и большая. Условия можно сочинять любые. Индексы , конечно помогут, но достаточно наличия по основным полям.
Во многих случаях запросы для отчетов - это то что надо.

 Отправлено: 25.03.11 01:04. Заголовок: Vlad04 пишет: Попро..

Vlad04 пишет:

цитата:

Попробуй запросы ADS.

Спасибо, но я не могу его использовать. Причины: он платный, и нужна еще отдельная локальная версия.
На LetoDB буду переходить. Но там пока индексы CDX (по отдельным файлам) не доделали ....

 Отправлено: 25.03.11 14:57. Заголовок: Причины: он платный..

цитата:

Причины: он платный,

Для отчетов можно использовать локальную версию - она бесплатная

 Отправлено: 25.03.11 15:42. Заголовок: Vlad04 пишет: Для о..

Vlad04 пишет:

цитата:

Для отчетов можно использовать локальную версию - она бесплатная

А смысл ? Для сети это будет тот же файл сервер, причем работать он будет не лучше, если не хуже, чем DBFCDX
Только ради sql-запросов ? Да и если запрос сделать неоптимально, он будет выполняться намного медленнее.
А чтобы его сделать оптимально, надо понимать, как его будет выполнять Ads, сможет ли он использовать индексы
Да и использование двух движков - ads для отчетов, dbfcdx для остального - это просто абсурд

 Отправлено: 25.03.11 20:11. Заголовок: А смысл ? Если ре..

цитата:

А смысл ?

Если результат, данные нескольких связанных баз, смысл применять ADS есть И код получается намного проще.Скорость, как правило в этих случаях не критична. Или 0.5 сек или несколько сек не так важно(нареканий не было).
Если же отчет - результат простого перебора данных таблицы , то ads не применяю.
Так ads в паре с dbfcdx применяю давно.

 Отправлено: 25.03.11 21:57. Заголовок: Речь идет об локальн..

Речь идет об локальном или настоящем Ads ? Если о настоящем, то он безусловно лучше, чем dbfcdx, если его конечно правильно использовать
Если о локальном - то безусловно хуже, поскольку мы имеем лишний слой в виде ace - adslocal
Дальше. Разговор здесь не шел о простоте кода в ущерб быстродействию. Наоборот, мы говорили об оптимизации тяжелых операций. И простотой кода в таких случаях надо жертвовать.
А использование sql в ads local в случае сложной выборки из нескольких таблиц не спасет.
В лучшем случае ads будет делать выборку тем же способом, как она делается ручками в dbfcdx. А может и хуже.
Но правильно построенную выборку средствами dbfcdx с помощью ads local превзойти не получится.
Совместное использование и ads, и dbfcdx я считаю бессмысленным
Если есть ads server, то надо использовать только его. Если нет - то смысла в использовании ads local нет. Но если уж хочется иметь такой суррогатный sql, то надо и для всех операций использовать только ads local. Тогда dbfcdx не нужен.

 Отправлено: 25.03.11 23:03. Заголовок: Vlad04 пишет: Если..

Vlad04 пишет:

цитата:

Если результат, данные нескольких связанных баз, смысл применять ADS есть И код получается намного проще

У меня несколько связанных баз. Смысла переделки под ADS нет, так как проще все делается на DBFCDX и времени нет по переходу на него. Я знаю, что локальный ADS будет медленней чем DBFCDX (в форумах давно читал).
А на настоящий переходить нельзя - лицензию заказчики оплачивать не будут, ради 3-10 рабочих мест.
Так что изучаем лучше матчасть - DBFCDX ....

 Отправлено: 24.01.15 14:58. Заголовок: Подскажите пожалуйст..

Подскажите пожалуйста как можно получить (просто для подсказки) выражение условного индекса ?
При уже построенном индексе.
Конечно можно запоминать в переменную, а потом выводить на экран, но это муторно...

 Отправлено: 24.01.15 15:05. Заголовок: IndexKey..

IndexKey

 Отправлено: 24.01.15 16:32. Заголовок: Dima пишет: IndexKe..

Dima пишет:

цитата:

IndexKey

Не то ! То же самое что и :
cText := " Ключ индекса: [" + DBORDERINFO( DBOI_EXPRESSION ) + "]" + CRLF

 Отправлено: 24.01.15 16:38. Заголовок: &(indexkey())..

&(indexkey())

 Отправлено: 27.01.15 14:49. Заголовок: Pasha пишет: Андрей..

Pasha пишет:

цитата:

Андрей, почему бы не сделать постоянный условный индекс с выражением: cIndexTo := "Str(NN)+PADL(ALLTRIM(FIELD->CNumKvar),5)" . . .

Мне кажется Str(NN) немного не корректно ... нужно PADL()