У меня такая проблемка.
Есть база на 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 флаг сброшен.

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

Кажется что-то вырисовывается.
Табл. около 40 полей
Я запрос делал select * from tabl Время больше 10 сек.
Выбрал только одно поле время ~1 сек.
Оставил только нужные поля около 15, время ~2-3 сек.

НО, МНЕ ВСЕ РАВНО НЕ ПОНЯТНО, В PARADOXE я целиковую таблицу выбираю за 1 сек.

Еще раз спасибо всем за отклики. :)

Провел более точные тесты.

PARADOX 9 -> BDE -> INTERBASE

VFP8 -> ODBC FIREBIRD DRIVER (или GEMINI ODBC Driver) -> INTERBASE

табл. в INTERBASE около 40 полей
тип данных
integer
numeric (15,2)
varchar(255)
date

кол-во записей табл. ~11тыс.

PARADOX 9 Tools ->utils-> copy
copy to file interbase -> name.db время ~6сек.
Размер файла db ~6МБ + индексы

copy to file interbase -> name.dbf время ~9-10 сек.
Размер файла db ~10МБ

VFP8
nConnHandle = SQLCONNECT('mybase', '', '')
lCommand= 'select * from tabledata'
lResult = SQLEXEC(gnConnHandle, lCommand,"tabledata")
время ~16-17 сек.
Размер файла dbf ~4,7МБ

Если выбирать не 40 полей, а 15 то
время ~2 сек.
Размер файла dbf ~1,2МБ

Andrey Ts
Судя по этому, влияет значение PacketSize для соединения! Попробуйте установить его 8192 или больше
Попробовал, особо не влияет.

Все, кажется разобрался. :)

Клиент на которой стоял PARADOX9, мой клиент на VFP8, и сервак на INTERBASE висели на одном свиче.
Софт и железо на клиентах,соединение с серваком, одно и тоже (поэтому я не стал писать о 2-х машинах предполагая что разница будет минимальной)
А оказалось меня перевели на другую схему, и я вижу сервак
через 3-4 свича :(

Естественно тесты получились разные.
Приношу свои извинения, если кого ввел в заблуждение.

Видимо все зависит от загрузки сети.

Сейчас я получил результат запроса из VFP8 в пределах 8-10 сек. (а час назад было 15-17 сек.), что сопоставимо с временем запроса из PARADOXa

Если поставить PARADOX на моем клиенте думаю время запросов будет одинаково.

Спасибо !