Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Обработка большой БД. Ошибка "...is too large" [D7, XP]

GEM © (2006-08-10 14:19:00)
Доброго времени суток!

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

GEM (2006-08-16 07:14:00) [1]

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

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

Lexiy (2006-08-15 17:14:00) [2]
к чему столько усложни отсев :)
вывод на экран более шести тысяч.
Да пользователь одну восьмую то не прокрутит рука устанет :)

GEM (2006-08-15 12:29:00) [3]

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

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

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

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

Anatoly Podgoretsky (2006-08-15 08:41:00) [4]
Шестой день продолжался допрос партизана.

GEM (2006-08-15 07:09:00) [5]
Пожалуйста помогите советом иль делом - очень нужно!

Mike Kouzmine (2006-08-14 11:19:00) [6]
Desdechado © (14.08.06 11:18) [8] Прошу прощения. Не увидел

Desdechado (2006-08-14 11:18:00) [7]
> INNERJOIN-ов n-ое количество, взависимости от того, какие
> и сколько полей выбрано
Вот здесь точномогут быть грабли. Проверь текст запроса. Похоже, что у тебя не наложено условие на соединение некоторых таблиц.

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

Mike Kouzmine (2006-08-14 10:54:00) [8]
Во-первых какая база. Подозреваю, что парадокс (бдешная оникбка, возникающая при неправильной работе с таблицами. Слишком большой файл блокировок.

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

Desdechado (2006-08-11 11:06:00) [10]
а запрос каков?

Desdechado (2006-08-11 11:06:00) [11]
подозреваю, у тебя декартово произведение получается

Sergey13 (2006-08-11 08:19:00) [12]
> [2] GEM (11.08.06 07:11)

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

GEM (2006-08-11 07:11:00) [13]
так я и выбираю только то, что указывает пользователь. В пределах 6000 записей в главной таблице работает все нормально, но мне необходимо обрабатывать все 300 000 записей, но здесь возникает вышеуказанная ошибка. Помогите, плз, ее обойти?

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »