Ограничение ресурса временной таблицы

Question

у меня есть два приложения (сервер и клиент), которые используют TQuery, связанный с TClientDataSet через TDCOMConnection, а в некоторых случаях клиентский набор данных открывает около 300000 записей, а затем приложение выдает исключение «Ограничение ресурса временной таблицы».

Есть ли обходной путь, как это исправить? (кроме "не открывать такой огромный набор данных"?)

обновление: ой, извините, есть записи 300K, а не 3 миллиона ..

Answer 1

Ошибка может быть из TQuery, а не из TClientDataSet. При использовании TQuery он создает временную таблицу, и это может быть этот предел, который вы бьете. Однако, говоря об этом, загрузка 3 000 000 записей в TClientDataSet также является плохой идеей, поскольку она будет пытаться загрузить каждую запись в память - что возможно, если они составляют всего несколько байтов каждая, но, вероятно, все еще убьет вашу машину (очевидно, на 1 КБ каждый вам потребуется минимум 3 ГБ ОЗУ).

Вы должны попытаться разбить ваши данные на более мелкие куски. Если это сбой TQuery, это будет означать корректировку SQL (меньше полей / меньше записей) или переход на лучшую базу данных (BDE все-таки немного устает).

Answer 2

У вас уже есть ответ. Не открывайте такой огромный набор данных в ClientDataSet (CDS).

Три миллиона строк в CDS - это огромная загрузка памяти (в зависимости от размера каждой строки она может быть гигантской).

Целью использования CDS является быстрая работа с небольшими наборами данных, которыми можно манипулировать в памяти. Добавление такого количества строк смешно; вместо этого используйте реальный набор данных или измените дизайн, чтобы вам не приходилось извлекать столько строк одновременно.

Answer 3

более 3 миллионов записей - это слишком много для одновременной обработки. Я предполагаю, что вы выполняете экспорт или что-то в этом роде, которое требует отправки большого количества записей по сети. Один из методов, который вы могли бы использовать, чтобы уменьшить эту проблему, состоял бы в том, чтобы средний уровень генерировал файл экспорта, а затем доставлял этот файл клиенту (предпочтительно сначала сжимая с использованием ZLIB или чего-то подобного).

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

EDIT

Даже 300 000 записей - это слишком много для одновременной обработки. Если бы у вас было столько копеек, вы бы смогли нести их все? Но если бы ты превратил это в более крупные деноминации, ты мог бы. если вы отправляете данные клиенту для отчета, то я настоятельно рекомендую метод сводки ... предоставьте им общую картину и позвольте им медленно углубляться в данные. отправьте сгруппированные данные, а затем медленно открывайте их.

Если это экран результатов поиска, установите ограничение на количество возвращаемых записей + 1. Например, для отображения 100 записей установите ограничение на 101. По-прежнему отображается только 100, последняя запись означает, что было более 100 записей, поэтому клиенту необходимо настроить критерии поиска для получения меньшего подмножества.

Answer 4

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

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

УДАЧИ