Выдрал OLE DB провайдер для Фокса из 2-го сервис-пака для Фокспра. Теперь практически все тесты OLE DB из конфы тестирования 1С++ падают с ошибкой:
Цитата:


А я ведь говорил, что самая правильная строка подключения - такая:
Цитата:


С такой строкой я даже не заметил перехода на новую разновидность провайдера.

Эх, вот не слушаете вы меня 

Кстати, вроде бы новый провайдер малость шустрее работает. Процентов эдак на 5.

kiruha писал(а) 03. Ноября 2007 :: 20:24:

Эта опция и раньше "не поддерживалась"  Можешь проверить

kiruha писал(а) 03. Ноября 2007 :: 20:30:

Ну и что, что стоит? Главное, она не поддерживается - т.е. не влияет ни на что 

kiruha писал(а) 03. Ноября 2007 :: 20:34:

Дык, смешно просто Если больше "не поддерживается", значит раньше поддерживалась типа

А вообще, я настаиваю на своем варианте строки подключения. В MSDN очень мало параметров у строки подключения для OLE DB. А та куча, что у тебя, скорее всего, включает параметры, которые раньше поддерживались ODBC-драйвером. А для OLE DB почти все это не нужно. Более того - вредно. Ибо может вылезти боком в случае изменения провайдера OLE DB, как это сейчас произошло.

kiruha писал(а) 03. Ноября 2007 :: 20:49:

Это она СЕЙЧАС влияет. Но в документации эта опция не указана. Поэтому, если в будущих версиях поддержку этой опции уберут, то они будут не так уж не правы. Потому что опция недокументированная. А таких вещей надо избегать.

А доверять установкам по умолчанию - как раз good. Ибо эти установки четко описаны в документации. Соответственно, fox эти вещи ОБЯЗАН поддерживать.

Если же ты не доверяешь установкам по умолчанию, то лучше использовать вещи типа SET и SYS.

kiruha писал(а) 03. Ноября 2007 :: 21:00:

Я вот как раз хотел спросить что-то такое у тебя

Uzhast писал(а) 03. Ноября 2007 :: 21:15:


SET FILTER - а какой ожидаемый эффект?

Specifies a condition that records in the current table must meet to be accessible.


SET FILTER TO [lExpression] [IN nWorkArea | cTableAlias]



Parameters
lExpression


Specifies the condition that records must satisfy. If the current table is indexed on a field or fields specified in lExpression, Rushmore Query Optimization technology can optimize queries based on the field or fields.
IN nWorkArea| cTableAlias


Specifies the work area or table alias affected by the SET FILTER command. Use this clause to specify a work area or a table outside the current work area.
Remarks
Once SET FILTER is issued, only the records that satisfy the condition specified by the logical expression lExpression are available in the table. All commands that access the table respect the SET FILTER condition. A separate filter can be set for every open table.

The condition specified by SET FILTER isn't evaluated until the record pointer is moved in the table.

Issuing SET FILTER TO without lExpression turns off the filter for the current table.

SELECT – SQL does not respect the current filter condition.

Эээ... В смысле, при использовании GOTO и SKIP

Nick писал(а) 05. Ноября 2007 :: 03:01:

Вообще, странно, конечно На форумах по фокспру так бодро советуют, как его использовать (Вроде, даже нашего Вадимко там видел ) Типа, ставим фильтр, потом достаточно переместить куда-нибудь текущий указатель (например, GO TOP) и все - фильтр работает. А я в prg все так и делал - эффекта 0. Вот и подумал, что это просто косяки OLE DB-провайдера. А, может, я его просто не так готовлю? 


Nick писал(а) 05. Ноября 2007 :: 03:01:

Точнее, в этой цитате просто говорится, что для гридов более подходящим будет использование SET KEY, потому что SET KEY работает исключительно на индексах. А SET FILTER может фильтровать не только по индексному выражению, но и по любому другому. Что в общем случае может быть медленным. Однако, если выражение фильтра попадает в индекс, то, по идее, SET FILTER по производительности не должен отличаться от SET KEY. Как на самом деле обстоят дела - не знаю. Да и в любом случае SET KEY не работает тоже


Nick писал(а) 05. Ноября 2007 :: 03:01:

Аж ностальгия прошибла  Я когда-то ведь знал про эту хреновину и даже использовал. А сейчас забыл все нахрен. Сейчас у меня используется некая рукопашная реализация SCAN. Не знаю, будет ли положительный эффект от перехода на явный SCAN?...

Nick писал(а) 06. Ноября 2007 :: 02:31:

Ага, фактически SCAN FOR может сделать SEEK вместо меня, если выражение попадает в индекс. Хм. Наверное, это все же медленнее, чем сделать SEEK напрямую... С другой стороны SCAN FOR позволяет использовать выражения. Сейчас у меня в провайдере для фильтров нужно указывать сырое индексное выражение (например "  1S20071101"). А со SCAN FOR появится возможность указывать что-то вроде такого: IDJournal + DTOS (Date) >= $ЖурналДокументов.Банковские + DTOS (:ДатаНачала~~). Смотрится вроде как лучше Надо будет проверить на скорость 

Неа, не делает SCAN FOR никаких сиков
Такой код

	SCAN FOR DTOS (Date) = '20071026'
		RETURN IDDocDef + IDDoc + DocNo + DTOS (Date)
	ENDSCAN 

Отрабатывает за 300-350 мс.

А такой:

	IF SEEK ('20071026')
		RETURN IDDocDef + IDDoc + DocNo + DTOS (Date)
	ENDIF 

За 30-40 мс.

Или я что-то не так делаю?

Nick писал(а) 06. Ноября 2007 :: 06:09:


Хотя если поставить SET TALK OFF то всё возвращается на место - раз в 15 медленее , или эта установка просто на scan не действует

Поэтому результаты для Фокспра могут быть не применимы в OLE DB.

Nick писал(а) 06. Ноября 2007 :: 06:25:

На основании документации и, в частности, списка неподдерживаемых команд в OLE DB
Так же вывод можно сделать на том факте, что не поддерживаются SET FILTER и SET KEY, хотя, по отзывам, многие нормально используют эти команды в нормальном фокспре.

OLE DB провайдер для VFP не использует НИКАКИХ внешних библиотек, кроме стандартных виндовых. Смотри "Dependency Walker"ом

Nick писал(а) 06. Ноября 2007 :: 06:30:

А на другом форуме (sql.ru) я читал, что в самом Фоксе SET FILTER и SET KEY работают

А вот для Scan  SET FILTER TO  работает
т.е. вот так:
SET FILTER TO Date == d
FOR i = 1 TO 10000
SCAN
     EXIT
ENDSCAN
NEXT i

Попробуй через провайдер, но результат тот же что и для SCAN FOR

Nick писал(а) 06. Ноября 2007 :: 06:35:

Ну вот, например http://www.sql.ru/forum/actualthread.aspx?bid=37&tid=330688&hl=set+filter:
Цитата:


Или из онлайнового МСДН http://msdn2.microsoft.com/en-us/library/52b84ce3(VS.80).aspx:
Цитата:


Так что дело темное...

О, только сейчас заметил, что у тебя GOTO 1, а не GOTO TOP. А с GOTO TOP не заработает? Вроде по МСДН должно сработать.

Uzhast писал(а) 06. Ноября 2007 :: 07:32:

с GOTO TOP РАБОТАЕТ!

Ну, OLE DB, погоди!

Хотелось бы узнать - новый провайдер был уже кем то испытан?
Можно его ставить в живую базу?
Какие то глюки не отмечены?