Дурацкий вопрос возник.. Вот я обращаюсь к файлу БД (dbf/dbase IV) посредством компонентов ADO из VBA(Excel). Мне нужно посчитать количество некоторых строк в файле/таблице БД и затем записать их в массив.

Есть два алгоритма:
1. посчитать количество строк средствами SQL языка, т.е. таким запросом:
почему-то конструкция не работает и пришлось так выкручиваться.. :( используя эти данные выделяем массив под строки
затем вторым запросом вытаскиваются сами строки и записываются в массив.
для каждого из запросов открывается рекордсет(!) просьба учитывать и это..

2. вытаскиваем данные запросом: затем курсором пробегаем все записи пересчитывая записи.. используется конструкция
после этого встаю снова на первую запись и заполняю массив..
при этом рекордсет открывается один раз..


Какой способ будет оптимальнее???

проходящий.,

я же написал, что он ругается на отсутствие оператора при использовании подобной конструкции.. да ивопрос в другом был пвообще-то...

проходящий.,

ок, сейчас приведу пример ошибки

Вот такая ошибки при таком запросе:

проходящий.Евгений_АнатольевичВот такая ошибки при таком запросе:


Это не ошибка фокса. Это ошибка VB. Покажите кусок кода, на который ругается.

на эту строку:

проходящий.Где-то что-то не так с настройкой рекордсета. Строка запроса вроде как должна быть передана объекту Command?
Короче, до фокса дело не доходит.

не обязательно создавать объект command для передачи запроса, можно и таким способом, но ради чистоты эксперимента я добавлю еще одно промежуточное звено в виде объекта Command и напишу результат.. :)

как я и предполагал.. точно такая же ошибка в момент исполнения: .Execute

проблема остается открытой..
ктсати про фокс никто и не говорил, что он глючит.. обращение вообще к (dbf/dbase IV) идет, что указано в 1 сообщение темы...

ну если проблема не в БД, то можно ли тред перенести в другой раздел? наверное лучше в форум по Visual Basic..

хотя вопрос был отчасти и по архитектуре построения запроса к БД..

проходящий.Единственное, что могу предложить - использовать VFP OLEDB Provider. Он такой синтаксис точно поддерживает. Во всех остальных случаях вопрос явно не в тот форум.

вообще-то использовать этот драйвер в данном случае неверно.. то соединение - которое использовалось является стандартом подключения к dbf/foxpro..

а по поводу соответствия тематики вы к сожалению не дочитали сам вопрос до конца.. :) Но спасибо, что попытались помочь и разобраться в друго проблеме.. :)

проходящий.,

http://connectionstrings.com/?carrier=dbffoxpro

:) никто и не спорит про другой форум.. скажем часть вопроса можно проще озвучить было:

что быстрее работает: подсчет строк средствами SQL языка или если пробежаться по рекордсету курсором?

потому что у меня и тот и другой случай приблизительно одинаково времени заняли "на глаз".. а хотелось бы точно знать.. ведь по идее запрос с COUNT должен работать оптимальнее..

с другой стороны во втором случае один раз идет обращение к БД а в первом два запроса.. т.е. оже различное время уйдет на обработку..

это проблема имеет 2 ракурса как со стороны программирования, так и со стороны оптимальных запросов к БД.. учитывая, что DBA у нас зачастую имеют приличный опыт еще и в программировании, ну и лучше ориентируются в скорости работы с такими БД как фокс или dbase - я и поместил вопрос сюда...

Fffffffffffff Евгений_Анатольевич!
По приведенной вами ссылке читаем
"For your foxpro 2.x DBF you do not need to use dBase or Jet driver, check out the "Visual FoxPro / FoxPro 2.x" section instead and use the VFP driver. Visual FoxPro ODBC and OLEDB drivers work for all Foxpro tables including the oldest foxbase tables and dBaseII, dBaseIII, Clipper files as well."

пытаюсь прикрутить обращения через драйвер VFP.. пока ругается на то что не может найти поставщика..

проходящий. ,

не стоит быть столь критичным.. людям свойственно ошибаться..

Модератор: Тема перенесена из форума "FoxPro, Visual FoxPro".

Люди, отзовитесь!!! :) Очень нужна помощь..

Игорь Горбонос
> Автор: Евгений_Анатольевич
> Люди, отзовитесь!!! :) Очень нужна помощь..

Этот
провайдер пробовали?

--
С уважением Горбонос Игорь Леонидович



Нет, и если честно - не понимаю почему при неправильном синтаксисе надо переходить сразу на других провайдеров :) Могу сказать на данный момент с уверенностью вот что: синтаксис запросов для провайдера Microsoft.Jet.OLEDB.4.0 (как минимум для файлов dbase IV) полностью идентичен синтаксису запросов в Access!!!!

Почему я это отверждаю? потому что первая проблема которая озвучена выше - имеет место быть с точно таким же описанием ошибки в Access!!! Только что создал в нем базу и проверил!!! Кроме того была проблема, которую не стал на форуме подымать, с JOIN синтаксис у которых в Access отличается от аналогичных функций в MSSQL!!!!

Теперь только осталось установить как же правильно использовать DISTINCT в запросах совместно с COUNT!!!

Вот такие пироги с котятами :) драйвера тут не при чем :)

HandKotа если сделать так



I Have Nine Lives You Have One Only
THINK!

А зачем? Не очень понял..

Порылся я на форуме..Подвожу итог изысканиям.. Действительно в отличие от MSSQL в запросах с использованием стандартного дравера следует применять именно такой корявый синтаксис для DISTINCT:

Теперь можно вернуться к первоначальному вопросу:
так какой же из алгоритмов все-таки оптимальнее и быстрее???

Игорь ГорбоносА здесь, я не понял, запрос всего один, и алтернативы я не вижу. Какие алгоритмы вы имели в виду?

текст взят из 1го сообщенияЕсть два алгоритма:
1. посчитать количество строк средствами SQL языка, т.е. таким запросом:
используя эти данные выделяем массив под строки
затем вторым запросом
вытаскиваются сами строки и записываются в массив.
для каждого из запросов открывается рекордсет(!)


2. вытаскиваем данные запросом:
SELECT DISTINCT NAME1 FROM DB ORDER BY NAME1
затем курсором пробегаем все записи пересчитывая их.. используется конструкция
после этого встаю снова на первую запись
и заполняю массив..
при этом рекордсет открывается один раз..

gjghjc,

я считаю не общее количество записей :) за идею использовать таймер - спасибо.. совсем забыл про такую фичу.. %)

gjghjc,

теперь понял! ведь во втором случаей действительно количество записей ограничено уже самой формой запроса.. хм.. получается, что сделать уже итоговую выборку эффективнее будет, потому что сам рекордсет всегда содержит количество полученных запросом записей(!)
спасибо!!! :)

Игорь Горбонос,

спасибо, приду домой - потестирую :)