Обработка большой БД. Ошибка "...is too large"

← →
GEM (2006-08-10 14:19) [0]

Доброго времени суток!

В базе FoxPro имеется 8 таблиц, из них одна главная, остальные детальные с первичными ключами. Соответственно чтобы вытащить иформационноемкие данные, необходимо их связать - для чего я использую ADOQuery, SQL запросы на выборку с INNERJOIN. Компонент для отображения данных - DBGrid. Иногда для выполнения определнной задачи мне достаточно использовать SQL с WHERE. Главная таблица может содержать в себе данные до 300 000 записей. 2 из детальных 10 000-20 000, остальные в пределах 1000 записей.
При запуске запросов спустя n-ое количество времени выходит ошибка "c:\docu~...\....tmp is too large". Можно ли как либо это обойти?
Второй вопрос: есть ли более оптимизированный подход чем мой с запросами для выборки данных из БД?

← →
Sergey13 © (2006-08-10 14:27) [1]

> [0] GEM (10.08.06 14:19)
> Второй вопрос: есть ли более оптимизированный подход чем
> мой с запросами для выборки данных из БД?

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

← →
GEM (2006-08-11 07:11) [2]

так я и выбираю только то, что указывает пользователь. В пределах 6000 записей в главной таблице работает все нормально, но мне необходимо обрабатывать все 300 000 записей, но здесь возникает вышеуказанная ошибка. Помогите, плз, ее обойти?

← →
Sergey13 © (2006-08-11 08:19) [3]

> [2] GEM (11.08.06 07:11)

1. Обрабатывать "все 300 000 записей" и показывать "все 300 000 записей" это разные вещи.
2. Оптимизировать запросы

← →
Desdechado © (2006-08-11 11:06) [4]

а запрос каков?

← →
Desdechado © (2006-08-11 11:06) [5]

подозреваю, у тебя декартово произведение получается

← →
GEM (2006-08-14 07:16) [6]

запросы образуются такого типа:
SELECT {поля, выбранные пользователем} FROM (главная INNERJOIN подчиненные ON главная.поле=подчиненные.поле
INNERJOIN-ов n-ое количество, взависимости от того, какие и сколько полей выбрано
При инициализации приложения заполняются Combobox-ы с помощью обычного запроса на выборку типа: SELECT DISTINCT поле FROM таблица, а некоторые наподобие запросом, но с WHERE - и уже при попытке забить Combobox-ы данными приложение ругается, что некий временный файл is too large
Как можно запросы такого типа оптимизировать?

← →
Mike Kouzmine © (2006-08-14 10:54) [7]

Во-первых какая база. Подозреваю, что парадокс (бдешная оникбка, возникающая при неправильной работе с таблицами. Слишком большой файл блокировок.

← →
Desdechado © (2006-08-14 11:18) [8]

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

Mike Kouzmine © (14.08.06 10:54) [7]
> Во-первых какая база.
Да в [0] написано же "В базе FoxPro".

← →
Mike Kouzmine © (2006-08-14 11:19) [9]

Desdechado © (14.08.06 11:18) [8] Прошу прощения. Не увидел

← →
GEM (2006-08-15 07:09) [10]

Пожалуйста помогите советом иль делом - очень нужно!

Шестой день продолжался допрос партизана.

← →
GEM (2006-08-15 12:29) [12]

> Шестой день продолжался допрос партизана.

партизанов...
Все же, можно ли решить данную проблему или нет?

> Вот здесь точномогут быть грабли. Проверь текст запроса.
> Похоже, что у тебя не наложено условие на соединение некоторых
> таблиц.

Однако ж, если главная таблица содержит менее 6000 записей (примерно), то никаких ошибок не выходит, как бы пользователь не извращался с выборкой. А тут даже при простейщем запросе типа SELECT DISTINCT поле FROM таблица WHERE поле=значение, уже ругается.

← →
Lexiy (2006-08-15 17:14) [13]

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

← →
GEM (2006-08-16 07:14) [14]

> Да пользователь одну восьмую то не прокрутит рука устанет
> :)

хотите сказать, что данный файл образуется при отображении данных, а не обработке? тогда как загружать частями данные в DBGrid?

Обработка большой БД. Ошибка "...is too large" Найти похожие ветки