У меня такая проблемка.
Есть база на Interbase, я соединяюсь через Firebird ODBC Driver
Делаю простую выборку базы в курсор. Табличка на 10 тыс. записей
Запрос идет около 10 сек. !!!
Аналогично делаю запрос в PARADOX 9 через BDE там курсор получается моментально!

Я так думаю в VFP медленно из-за преобразования форматов полей таблицы, конвертирования данных .

Может у кого есть опыт работы с ibase из VFP.
Может какие другие способы связи попробовать (ADO OLE DB ???)

У меня такая проблемка.
Есть база на Interbase, я соединяюсь через Firebird ODBC Driver
Делаю простую выборку базы в курсор. Табличка на 10 тыс. записей
Запрос идет около 10 сек. !!!
Аналогично делаю запрос в PARADOX 9 через BDE там курсор получается моментально!

Я так думаю в VFP медленно из-за преобразования форматов полей таблицы, конвертирования данных .

Может у кого есть опыт работы с ibase из VFP.
Может какие другие способы связи попробовать (ADO OLE DB ???)

leafдля делфи парадокс и интербейс почти родные форматы поэтому и быстро
а вы не пробывали в бде из интербейса в дбф гнать
и вообще скорость формирования определяеться качеством одбс драйверов
если делфи делает такие дрова так что вы хотите
работайте на делфи с родными дровами а если нужен фокспро то может лучше скл_сервер ????

По моему вопрос стоял так- "работа из VFP c IBASE", то что на дельфе и парадоксе с родной sql ,быстрее - это и коню понятно.

piva вечный глюк с включенными Tracing в ODBC Sources Панели управления

Спасибо за отклики :)
А можно поподробнее что за глюки и как избавиться?
У меня на вкладке Tracing в ODBC вроде остановлен

Может это я где-то туплю вот , что я делаю:

gnConnHandle = SQLCONNECT('mybase', '', '')
lCommand= 'select * from tabledata'
lResult = SQLEXEC(gnConnHandle, lCommand,"tabledata")

Во время выполнения сообщение выполняемого запроса 'Executing remote... Press ESC to cancel' после ~10 секунд получаю курсор

Типы полей IBASE используемые в табличке:
integer
numeric (15,2)
varchar(255)
date

после получения результата поле varchar(255) становиться memo, а date -> datetime
Мож с этим что связано?
Кстати я раньше пользовался утилиткой IBAdmin для получения dbf и по скорости конвертирования очень похожие результаты.
Я даже вижу колличество конвертируемых записей по 300-600 в секунду
Да , еше база на ibase с довольно сложной структурой и на эту табличку навешано куча связей, индексов, триггеров и т.п. Может это влияет?

vl2000Сервер FB1.5 (локально) + VFP80 + ODBC Easysoft IB60
(извиняюсь, засекал по секундомеру)

А если сервак на другой машине? Сколько будет?

Кажется я плохо описал свою проблему.

vl2000 Запусти свой запрос напрямую на сервере (например из IBExpert). Посмотри, какое будет время выполнения запроса.

IBExpert это не VFP8
Меня интересует курсор полученный в VFP8

Я же говорю, в PARADOX 9 сделал алиас в BDE на ту же базу получил результат такого-же запроса моментально.

В IBADMIN эта таблица тоже открывается моментально, а тормоза начинаются при конвертировании ее в dbf. Это очень похоже на получение курсора в VFP8 через ODBC из табл. INTERBASE

Igor Korolyov
Hi Трехсотый!

Ни один SQL-сервер не рассчитан на то что его будут ТАК использовать. Какой
смысл вообще в сервере, если ты не работать его заставляешь, а банально
качать инфу туда-сюда? Если ты ТАК хочешь работать - переходи на технологию файл-сервера.
В клиент-сервере принято выбирать лишь минимально необходимый набор записей. Posted via ActualForum NNTP Server 1.1

Ну, во первых инфу качаю только "сюда" ;)
Данные нужны для построения отчета.
Причем все! данные!

Igor Korolyov
Я НИКОГДА не поверю что тебе постоянно нужно вынимать оттуда по 10000
записей.
Posted via ActualForum NNTP Server 1.1
Почему??? Формируешь отчет и выгребаешь все данные за год.
Это один вариант самый простой.
А теперь представь существуют 2 задачи одна на fox другая на IBASE, нужен анализ данных из этих задач, причем основное поле с кодом по которому строится отчет в одной задаче символьного типа в другой числового. Хочешь не хочешь придется выгружать всю табл. во временный курсор и приводить к общему типу данных , группировать объединять, суммировать и вываливать в общий отчет.
Могу придумать еще варианты....
Потом 10 000 записей это мелочь для простых запросов. Что доказывает работа даже через BDE из того же PARADOXA или DELPHI , не говоря о других способах доступа. И VFP их так же должен глотать, но в чем причина, я подозреваю в конвертации данных?
Igor Korolyov
Теперь по поводу BDE - а с чего ты взял что по BDE сразу вынимаются все
10000 записей? Он как раз так не делает, а забирает их порциями, причём
весьма себе скромными! Например чтобы показать в гриде вмещающиеся там 10-20 записей. Ну а уж если его напрягут гнать все 10000 скажем в отчёт, или
просто в файл какой - думаю он будет ненамного быстрее работать, даже с
учётом "прямого" доступа к серверу.
Posted via ActualForum NNTP Server 1.1

Так я и делаю для отчета запрос и в PARADOX табл ANSVER (наш курсор) получается моментально, и на диск сохраняется моментально.

vl2000Ну если ты уверен, что проблема не в IB, то попробуй другой ODBC.
Например Easysoft или Gemini.

Уже попробовал Gemini , таже ситуация.

В общем не стоит акцентировать внимание на 10 000 записей. Лучше узнать почему такая разница во времени при обработке совершенно одинаковых запросов разными СУБД.

Да забыл сказать:
В общем, дальше с полученным курсором VFP работает моментально, все остальные операции по преобразованию (гораздо трудоемкие) пролетают незаметно.

leafкажеться вы нам голову морочите что за отчет на 10000 строк кто его анализирует его даже в ексель бы не стал пихать не захотел бы связываться
что-то тут не так
может способ всетаки не тот а

Нет не морочу, в этом случае получается в итоге 2тыс. записей.
Код структуированный по нему просчитываются все промежуточные итоги, которые тоже попадают в отчет.

А есть отчеты импорт. в Excel и по 20 тыс. строк.
И поверьте, анализируют, еще как анализируют!!!!

vl2000
У меня:
Record to fetch at a time стоит ALL
Maximum record to fetch стоит ALL
Asynchronous execution флаг сброшен.

Сделал тоже самое результат тот же