EDBEngineError

← →
Climber © (2006-10-09 06:37) [0]

Где фиксить EDBEngineError "Temporary table resourse limit"?.
Спасибо.

← →
Desdechado © (2006-10-09 10:48) [1]

Судя по тексту, исчерпан ресурс создания временных таблиц в БДЕ. Либо слишком много открытых запросов одновременно, либо они слишком опухшие.

← →
Climber © (2006-10-09 15:43) [2]

это я понял. вот и спрашиваю, может где в настройках БДЕ это можно поправить...

← →
Desdechado © (2006-10-09 15:58) [3]

Лечить нужно не симптомы, а болезнь. Т.е. не городить кучу открытых запросов и огромного размера результатов.
С настройками можно поиграться, но это только отсрочит смерть.
BDE Admin - Configuration - System - INIT
+ F1 на каждом параметре

← →
Climber © (2006-10-09 17:45) [4]

открытых запросов 2, а огромного размера результата не избежать.. вот и бьюсь..

← →
ЮЮ © (2006-10-10 03:03) [5]

Тогда, получается, исчерпан ресурс временной таблицы? :) Но у таблицы то ресурсов - размер файла и количество полей. Но в этом случае и сообщения другие должны быть, ИМХО.

Для начала поставь в запросах WHERE, ограничивающее объем НД. Ошибка исчезает?

← →
Игорь Шевченко © (2006-11-07 12:13) [6]

Столкнулся с аналогичной проблемой. Запрос по частям разбивать не хочется, записей в результате запроса больше полумиллиона, запись довольно длинная (~ 40 полей со средней длиной поля порядка 50 символов).
Если кто знает, как побороть, просьба пнуть в нужном направлении. Block Size у драйвера Paradox выставлен по максимуму (в 32К) - на проблему не влияет. У читающей Query выставлено UniDirectional в true, на проблему не влияет.

← →
Desdechado © (2006-11-07 13:05) [7]

Если я правильно помню, временные таблицы создаются в том формате, который указан в BDE Admin - Configuration - System - INIT - Default driver
Если проблемы с парадоксовским форматом временных таблиц, можно попробовать dbase. Он не такой капризный, и я его использую для этих целей. Проблем не имел, хотя 40 полей по 50 байтов на поле * 500 тыс записей - не помню таких выборок у себя.

← →
sniknik © (2006-11-07 13:06) [8]

114 Temporary table resource limit.

Problem: Getting error "Temporary table resource limit."

When running a query
Versions: All

Possible causes:

* If you"re joining three or more large tables, try to split the query in two
* There"s not enough space on the drive where your private directory is
* There"s not enough space on the drive where your Windows TEMP folder is
* This could be a variation of the "Insufficient disk space." error
* This could be caused by the blocksize for the table being too small.
* This can happen if the resulting answer table will be larger than 512 MB and the query includes sorting and removing duplicates, that is a query with Check. When tables are that large, use CheckPlus to skip the sorting.

← →
Desdechado © (2006-11-07 13:06) [9]

> У читающей Query выставлено UniDirectional в true, на проблему не влияет.
И не должно, ибо временный файл создается до того, как результат выборки попадает в квери. А UniDirectional влияет только на буферизацию внутри программы, а не на внешний файл.

← →
sniknik © (2006-11-07 13:09) [10]

40*50*500000 - 953мг.
> This can happen if the resulting answer table will be larger than 512 MB ....

← →
Игорь Шевченко © (2006-11-07 13:41) [11]

sniknik © (07.11.06 13:06) [8]

База данных из откуда производится выборка - Interbase (Firebird). Если BDE под результат каждого запроса создает парадоксовскую таблицу, то я не совсем понимаю.
Почему не хочу разбивать запрос - запрос служит источником для перегрузки в другой формат и городить огород в данном случае не представляется целесообразным.

> * If you"re joining three or more large tables, try to split
> the query in two

Нет, таблица одна.

> * There"s not enough space on the drive where your private
> directory is

Навалом спейса. 17 гигабайт минимум.

> * There"s not enough space on the drive where your Windows
> TEMP folder is

Навалом спейса.

> * This could be a variation of the "Insufficient disk space.
> " error

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

> * This could be caused by the blocksize for the table being
> too small.

Blocksize менялся с 2048 до 32768 - эффект от изменения BlockSize не замечен.

> * This can happen if the resulting answer table will be
> larger than 512 MB and the query includes sorting and removing
> duplicates, that is a query with Check. When tables are
> that large, use CheckPlus to skip the sorting.

Сортировки нету.
Запрос выглядит как
select
Field1,
Field2,
Field3,
Field4,
.... далее со всеми остановками до станции Можайск
from
Table1
where
Field3 <> someliteral;

Desdechado © (07.11.06 13:06) [9]

> И не должно, ибо временный файл создается до того, как результат
> выборки попадает в квери. А UniDirectional влияет только
> на буферизацию внутри программы, а не на внешний файл.

С этого места пожалуйста подробнее - что за внешний файл, когда содается, где про это написано, как избавиться ?

← →
Desdechado © (2006-11-07 13:53) [12]

> что за внешний файл, когда содается, где про это написано, как избавиться ?
Дык, БДЕ при выполнении запросов практически всегда (кроме очень мелких результатов) сбрасывает результаты на диск в Session.PrivateDir. Причем, как я писал в Desdechado © (07.11.06 13:05) [7], в формате default driver.
Избавиться от этих файлов, имхо, невозможно. А вот форматом можно попробовать поиграться.

← →
Anatoly Podgoretsky © (2006-11-07 14:01) [13]

> Игорь Шевченко (07.11.2006 13:41:11) [11]

> Если BDE под результат каждого запроса создает парадоксовскую таблицу

Не обязательно, зависит от драйвера по умолчанию, и временные таблицы часто создаются для формирования результата, так же как и в других СУБД, просто БДЕ имеет сильные ограничения на размер и другие вещи, все таки он ориентирован на FAT и разработан ой как давно.

> Навалом спейса. 17 гигабайт минимум.
Не играет роли, ограничение на файлы идет по ДОСу

> С этого места пожалуйста подробнее - что за внешний файл, когда содается, где про это написано, как избавиться ?

Никак, принципы работы, UniDirectional тут не причем, в случае UniDirectional такой файл всегда создается. При том создается не один файл, создается в папке PrivateDir

Попробуй сменить драйвер по умолчанию на dBase может поможет, все таки более простой и экономный формат, особенно dBase VII.

← →
Jeer © (2006-11-07 14:02) [14]

> Игорь Шевченко © (07.11.06 13:41) [11]

> База данных из откуда производится выборка - Interbase (Firebird).

> Если BDE под результат каждого запроса

Зачем тут BDE ?

Почему бы ODBC, например, не использовать ?

← →
Игорь Шевченко © (2006-11-07 14:07) [15]

Desdechado © (07.11.06 13:53) [12]

Попробовал поменять Default Driver с Paradox на Dbase и FoxPro. Результат не изменился ни на йоту. Как застревала на 457856-й записи при последовательном чтении, так и продолжает.
Сокращение количества полей в запросе помогает, но поля-то нужны.
Не хотелось бы отказываться от BDE, может как-то можно полечить...

← →
Desdechado © (2006-11-07 14:14) [16]

> Попробовал поменять Default Driver с Paradox на Dbase и FoxPro. Результат не изменился ни на йоту.
После изменения настроек БДЕ нужно перестартовывать приложения, использующие БДЕ, чтобы изменения вступили в силу.

← →
Игорь Шевченко © (2006-11-07 14:22) [17]

Jeer © (07.11.06 14:02) [14]

> Зачем тут BDE ?
>
> Почему бы ODBC, например, не использовать ?

Не хотелось бы обсуждать вопрос BDE / не BDE.

В самом последнем случае будут использоваться стандартные компоненты доступа к Interbase, но это приведет к довольно большим изменениям, а это время.

← →
Игорь Шевченко © (2006-11-07 14:23) [18]

Desdechado © (07.11.06 14:14) [16]

> После изменения настроек БДЕ нужно перестартовывать приложения,
> использующие БДЕ, чтобы изменения вступили в силу.

Даже если бы ты не написал этой фразы в форуме ее пишет BDE Administrator :)

← →
sniknik © (2006-11-07 14:50) [19]

по моему единственный вариант остался - делить запрос на несколько.

а кстати, поля какого типа char(50) или varchar(50)? если это имеет значение для BDE/найтивных драйверов :), там же нет строк с переменной длинной.
может размер им "пооптимизировать"? ;) (ну если в какоето максимум 5 символов пишут, а оно по общему формату = 50... в BDE то сделает во временной по определяемому размеру а не по фактическому... лишние мегабайты)
даже если нельзя менять структуру но можно же
select
CAST(Field1 AS Char(20)), //хотя само поле Char(50), но там всего 20 значимых
CAST(Field2 ...
...
попробовать так.

← →
Anatoly Podgoretsky © (2006-11-07 14:55) [20]

> Игорь Шевченко (07.11.2006 14:07:15) [15]

Оно не обязано прислушиваться, особенно раз речь про Interbase, но оно может прислушаться.
Драйвер FoxPro не родной, ограниченый, мне помогала установка драйвера dBase IV после этого у меня стали создаваться _sql....dbf файлы

← →
Desdechado © (2006-11-07 16:18) [21]

Обходной маневр, но все же:
можно пропробовать в самом IB создать EXTERNAL TABLE c символьными полями, куда выгрузить внутренним запросом типа INSERT... SELECT... нужные данные. А уж потом играться с текстовиком.
ЗЫ Если создать не символьные поля, то всякие INTEGER будут в бинарном виде туда запиханы.

← →
Игорь Шевченко © (2006-11-07 16:24) [22]

sniknik © (07.11.06 14:50) [19]

Вариант - это я IBExpress"ом буду пользоваться, если нету гайки в BDE
glitch=false

Я, собстна, обратился к сообществу с целью поиска той самой гайки.
Запрос разделять я не буду принципиально, объяснять причины этой принципиальности не буду тоже :)

← →
Anatoly Podgoretsky © (2006-11-07 17:03) [23]

Трудно найти эту гайку в БДЕ
Не расчитано оно было на это

← →
Игорь Шевченко © (2006-11-09 11:47) [24]

На всякий случай, может, кому интересно - у IBExpress обнаружились свои глюки.
Получается, что для последовательного чтения данных большого запроса, возвращающего много некоротких полей, среди которых встречаются BLOB"ы, желательно использовать что-то совсем примитивное, не кэширующее и не буферизующее данные. Например, DbExpress.

← →
Jeer © (2006-11-09 11:55) [25]

> у IBExpress обнаружились свои глюки.

Кто бы сомневался: вся жизнь - борьба с глюками, ладно бы только со своими.:)

IBExpert ?

← →
sniknik © (2006-11-09 12:14) [26]

> желательно использовать что-то совсем примитивное, не кэширующее и не буферизующее данные. Например, DbExpress.
попробуй еще ADO ;о)), OLEDB драйвер можно вот этот
http://www.zstyle.com.ua/rus/iboledb_prod.htm
у меня с ним получались довольно большие выборки (обмен), и без всяких проблем насколько помню (параметры записи, и количество строк указать не смогу, не помню).
причем никаких "извращений" типа подбора режима выборки не делал, пользовался по умолчанию клиентским курсором и двунаправленным рекордсетом (все одно все данные мне нужны были на клиенте + отображать в гриде тоже нужно было. т.е. ... ну понятно ;о))

← →
ANB © (2006-11-09 12:24) [27]

> Игорь Шевченко © (09.11.06 11:47) [24]

TOracleQuery (из DOA). К сожалению, это тебе не подойдет, но можно поискать аналоги.

← →
ANB © (2006-11-09 12:33) [28]

По аналогии могу предположить, что нужен не наследник TDataSet. Из вкладки InterBase я накопал TIBSQL.
Из dbExpress может подойти TSQLQuery (хоть он и является наследником TDataSource). Ща попробуй выгрести им немелкую таблицу из оракла

← →
Игорь Шевченко © (2006-11-09 12:48) [29]

Jeer © (09.11.06 11:55) [25]
sniknik © (09.11.06 12:14) [26]
ANB © (09.11.06 12:33) [28]

У меня задача выгрузить из базы данных в некий (неважно какой) внешний источник все данные. Одним запросом. В таблице базы данных порядка миллиона записей, в каждой записи приличное количество полей.
База данных - Firebird.

Единственное, до чего я не дошел - это до ADO, ну и ладно. Наследник DataSet нужен бо удобно Open, Close, Next, Eof и FieldByName

← →
ANB © (2006-11-09 12:59) [30]

> Игорь Шевченко © (09.11.06 12:48) [29]

Выгружать построчно собираешься ? Или хочешь извратиться с гетерогенным запросом ?

Те компоненты, которые я нарисовал поддерживают методы навигации. Нету только редактирования. А TSQLQuery - однонаправленный (почему я и думаю, что он не кэширует все на клиента). Эта, очепятался я. Наследник он TDataSet.

← →
Anatoly Podgoretsky © (2006-11-09 13:00) [31]

> Игорь Шевченко (09.11.2006 12:48:29) [29]

Про АДО могу сказать, что пробовал выгружать 6 миллионов записей в двухнаправленый, локальный курсор, проблем у меня не было, правда и БЛОБ полей тоже. Попробуй, едиственная проблема найти правильный OLE DB провайдер для Интербейс, просто по этому поводу много наслушался нелестных слов.

← →
ANB © (2006-11-09 13:02) [32]

TSQLQuery 40 тыщ записей выгреб без напряга. Память практически не уел (во всяком случае она не елась при закачке).
ЗЫ. Мне тоже как то нужно было перекачать пару миллионов записей из оракла в ms sql с обработкой на клиенте. Сначала качал через TOracleDataSet. Он ужрал пройденными записями весь файл подкачки и отвалился таки из-за нехватки памяти. Поменял компонент и все заработало.

← →
ANB © (2006-11-09 13:05) [33]

Накопал табличку на 10 лимонов записей. ща ее попробую качнуть

← →
ANB © (2006-11-09 13:09) [34]

один лимон прошел. полет нормальный, память не жрет.

← →
ANB © (2006-11-09 13:14) [35]

второй лимон прошел. уел лишних 32Кб памяти. возможно из-за того, что я сворачивал/разворачивал окошко.

← →
Anatoly Podgoretsky © (2006-11-09 13:22) [36]

> ANB (09.11.2006 13:09:34) [34]

Время тоже сообщи.
Для MS SQL 6 миллионов, несколько секунд, машина не то чтобы слабая, но и не мощная - 512 мб памяти. Сеть 100 мбит

← →
sniknik © (2006-11-09 13:27) [37]

ANB
размер записи? без этого тест смысла не имеет.

Игорь Шевченко © (09.11.06 12:48) [29]
> Единственное, до чего я не дошел - это до ADO
самое время попробовать. ;о)) может не дошел как раз до того что бы тебе подошло...
тебе даже писать ничего не надо, скачаешь указанный драйвер, установишь (простая регистрация сом обьекта), я тебе вышлю тестовую программку в ней создашь коннект к база и выполнишь запрос к проблемной таблице...
выполнится значит подходит, ошибка - нет, если не устроит скорость открытия но всетаки открывает значит можно использовать с дополнительными настройками по режиму открытия (у меня локальный/двунаправленный т.е. как я обычно использую)

> FieldByName
вот FieldByName я бы не рекомендовал в длинных циклах использовать, только до, для определения переменных TField, а в цикле уже их. дает небольшую экономию времени.

← →
ANB © (2006-11-09 13:44) [38]

Прокачалось 10 лимонов записей. Записи короткие. Качалось долго (минут 15), но это все на локальном оракле + я выводил записи на экран. Проц был ужрат процентов на 90 (где то 50 ужел оракл и 40 - приложение). Память приложение практически не уело, из чего можно сделать вывод, что записи не кэшировались. FB по рукой нету, так бы на родных компонентах потренировался.

← →
ANB © (2006-11-09 13:46) [39]

> Записи короткие

байт 30 в сумме. Однако 10 000 000 * 30 = 300 метров (это без накладных расходов). Приложение как съело 10 метров, так и с ними работало. чуток тока дергалось после каждого лимона.

← →
Игорь Шевченко © (2006-11-09 15:04) [40]

ANB © (09.11.06 12:59) [30]

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

sniknik © (09.11.06 13:27) [37]
Anatoly Podgoretsky © (09.11.06 13:00) [31]

> Про АДО могу сказать, что пробовал выгружать 6 миллионов
> записей в двухнаправленый, локальный курсор, проблем у меня
> не было, правда и БЛОБ полей тоже. Попробуй, едиственная
> проблема найти правильный OLE DB провайдер для Интербейс,
> просто по этому поводу много наслушался нелестных слов.
>

До ADO просто руки не дошли.
Провайдер для Firebird где-то валяется, скачанный с IBPhoenix.

Идеальным вариантом, наверное была бы прямая работа с клиентской библиотекой Firebird, поскольку мне требуется двигаться по полученному Resultset"у только вперед, то, что прочитано, сохранять не надо, но читать хотелось бы максимально быстро, без двунаправленности, без сохранения результатов запроса в промежуточный файл, и т.д.
Но для идеального варианта, боюсь, придется много писать, а в особенности с BLOB-полями.

← →
sniknik © (2006-11-09 15:22) [41]

> До ADO просто руки не дошли.
> Провайдер для Firebird где-то валяется, скачанный с IBPhoenix.
нет. если будеш пробовать, то возьми по ссылке, я в свое время тестил все что нашел (6-7 шт), этот подошел лучше всего. у остальных чтото да не то было. и хотя уже много времени пришло, у кого были глюки наверняка исправили, но без дополнительный тестов я бы не рисковал. гарантий не дам в общем. ;о)

> но читать хотелось бы максимально быстро, без двунаправленности
не проблема, есть такой режим, просто предлагал проверить в наихудшем для тебя варианте, уж если он потянет, то однонаправленный для него(ADO) будет вообще как семечки.

и еще, у меня получалось время передач данных (сумма времен выборка + запись. т.е. с проходом до конца рекордсета. а не просто открытие) быстрее именно в моем варианте (почему и пользуюсь), предположительно (по догадкам) потому что когда забирается весь рекордсет он архивируется (по другому не получается обьяснить... почему быстрее) в отличие от позаписьной передаче на серверном курсоре, но вот как оно поведет себя на обьемах когда и память и кеш кончились... не знаю, надо тестировать. (вобще, все надо тестировать на реальном... ;о))

> а в особенности с BLOB-полями.
данные BLOB-поля в рекордсете не представлены, только ссылки. при обращении скачиваются с сервера.

← →
Игорь Шевченко © (2006-11-09 15:31) [42]

sniknik © (09.11.06 15:22) [41]

> если будеш пробовать, то возьми по ссылке

http://www.zstyle.com.ua/files/ibfree5.zip - The page cannot be found

← →
ANB © (2006-11-09 15:31) [43]

> Игорь Шевченко © (09.11.06 15:04) [40]

ну так попробуй интербейзом. все нужные свойства и методы у компоненты есть.

← →
Anatoly Podgoretsky © (2006-11-09 15:33) [44]

> Игорь Шевченко (09.11.2006 15:04:40) [40]

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

← →
Игорь Шевченко © (2006-11-09 15:39) [45]

Anatoly Podgoretsky © (09.11.06 15:33) [44]

Собственно, в эту сторону и посмотрел. Пока не глючит.

← →
sniknik © (2006-11-09 15:46) [46]

> - The page cannot be found
понятно, это видимо изза перестройки сайта

а так?
ftp.prima.susu.ac.ru/pub/outgoing/IB/OLEDB_Prov/ibfree5.zip

← →
Игорь Шевченко © (2006-11-09 16:05) [47]

sniknik © (09.11.06 15:46) [46]

Так сработало, спасибо. О результатах (if any) расскажу позже.

← →
Petr V. Abramov © (2006-11-09 18:47) [48]

Игорь Шевченко © (07.11.06 13:41) [11]
Я б посмотрел в сторону внешних таблиц в FB, чтоб в корне зло пресечь.

← →
Игорь Шевченко © (2006-11-09 22:35) [49]

Petr V. Abramov © (09.11.06 18:47) [48]

Внешние таблицы тут не совсем. Мне как раз надо из Firebird выгрузить, причем, с неким преобразованием. Программкой оно проще всего, я не предполагал, что простое движение по ResultSet"у вызовет такие проблемы на больших объемах.

← →
Johnmen © (2006-11-09 22:51) [50]

> Игорь Шевченко ©

Я что-то упустил или TIBSQL из IBX не подходит?

← →
Jeer © (2006-11-10 10:32) [51]

Игорь Шевченко © (09.11.06 22:35) [49]

> простое движение по ResultSet"у вызовет такие проблемы на
> больших объемах.

Мне как-то пришлось откатывать все операции по вкладам Сбербанка от декабря к марту, скорректировать неверный метод расчета и подкатить обратно к декабрю.
Сделал просто - выгнал все в dbf и прямым самописным доступом издевался над данными сколько влезет.
Уж не помню сколько винтов ушло под это дело:))

← →
Jeer © (2006-11-10 10:34) [52]

Игорь Шевченко © (09.11.06 22:35) [49]

И кто или что мешает делать подвыборки приемлимого обьема и работать с ними по очереди ?

← →
Игорь Шевченко © (2006-11-10 14:42) [53]

Johnmen © (09.11.06 22:51) [50]

> Я что-то упустил или TIBSQL из IBX не подходит?

Выдает ошибку Out of memory в относительно произвольный момент времени. В отладчике совершенно бредовые цифры (пытается 70 мегабайт выделить ни с того ни с сего).

Jeer © (10.11.06 10:34) [52]

Я как-то выше сказал, что разделять результат запроса не хочу и объяснять причины этого нехотения не хочу тоже :) Кроме всего прочего нет четкого критерия для разделения, а хотелось бы сделать на все варианты случаев жизни и забыть.

← →
Jeer © (2006-11-10 14:51) [54]

Игорь Шевченко © (10.11.06 14:42) [53]

Если записи обрабатываются последовательно и алгоритм обработки (экспорта) включает только одну текущую запись - выборка делается по приемлимому количеству записей.

← →
Anatoly Podgoretsky © (2006-11-10 15:00) [55]

> Jeer (10.11.2006 14:51:54) [54]

Top N where ID > LastProcessesID
Если поле автоинкриментного типа

← →
Jeer © (2006-11-10 15:09) [56]

Anatoly Podgoretsky © (10.11.06 15:00) [55]

В IB/FB нет автоинкремента.

← →
Johnmen © (2006-11-10 15:28) [57]

> Игорь Шевченко © (10.11.06 14:42) [53]
> Выдает ошибку Out of memory в
> относительно произвольный момент времени. В отладчике совершенно
> бредовые цифры (пытается 70 мегабайт выделить ни с того
> ни с сего).

Сервер на той же машине, что и приложение?

← →
Игорь Шевченко © (2006-11-10 15:40) [58]

Johnmen © (10.11.06 15:28) [57]

> Сервер на той же машине, что и приложение?

На ошибку это не влияет.

Мне всего лишь надо последовательно прочитать таблицу, сделать с половиной полей по три операции мамбл-ванго, остальные оставить без изменения, и записать получившуюся запись в <другое место>. Все. Никакой буферизации, никакой двунаправленности, никакого кеширования мне не требуется. Таблиц около 10, с каждой надо проделать подобные действия, средний размер каждой - миллион записей.

← →
Anatoly Podgoretsky © (2006-11-10 15:41) [59]

> Jeer (10.11.2006 15:09:56) [56]

> В IB/FB нет автоинкремента.

Я знаю, просто забыл добавить слово типа, но мы то достаточно развиты, что бы понять, если подобное поле есть, которое постоянно только увеличивается, тогда использовать его для работы по частям.
В MS SQL например есть еще и тип TIMESTAMP - это совсем другое, чем в IB/FB - это как раз строго по названию временная метка, последней модификации строки, так что вопрос не в терминологии, а в том что для данной цели подходит автоинкрементное (логически) поле.

Но мы ничего не знаем про его запросы на сервер, может его запросы не позволят подобный механихм использовать.

← →
Jeer © (2006-11-10 15:56) [60]

Anatoly Podgoretsky © (10.11.06 15:41) [59]

Даже если нет таких полей - добавить и навесить генератор.
Как вариант.

P.S.
Сделал тестовую табличку FB.
40 полей varchar 50.
Сгенерил рандом средней длиной 45
Объем файла более 2G - так,что BDE, а также ODBC через TQuery - отдыхают.
Ограничение 2G.

Попробовал IBExpert - он сделал два вздоха по 150тыс записей и воткнул тачку с 1G memory в out of того самого.

← →
Anatoly Podgoretsky © (2006-11-10 16:12) [61]

> Jeer (10.11.2006 15:56:00) [60]

Я и говорил, если нет физических, то использовать логические или другие поля, которые имеют подобное поведение, поля в которых каждое новое следующее значение больше предыдущего.
Типа автоинкримент, вот например типа TIMESTAMP или GUID не подойдут, а вот номер чего то вполне.

Но это если запросы Игоря позволяют это делать, тогда можно даже до абсурда довести, а может это и не абсурд, брать по одной записи.

← →
ANB © (2006-11-10 16:25) [62]

> Anatoly Podgoretsky © (10.11.06 16:12) [61]

в оракле/ФБ/ИБ для этого используются генераторы/сиквенсы.

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

> ANB (10.11.2006 16:25:02) [62]

Я в курсе, ФБ/ИБ не имеет автоинкриментных полей, про Оракл не в курсе, но для эмуляции у них есть генераторы или Sequence

> но для эмуляции

Я бы сказал, это у MS SQL попытка эмуляции генераторов/сиквенсов, причем с меньшей функциональностью и некоторой неудобностью.

> ANB (10.11.2006 16:32:04) [64]

Я бы не сказал, чистые автоинкриментные поля, но спорить не будем, не принципиально это.

> но спорить не будем, не принципиально это.

Не, таки будем :)
Генераторы/сиквенсы поудобнее в эксплуатации будут. У них только один минус - их надо отдельно создавать.
Основное их преимущество - возможность доставать ID до вставки.

Игорь Шевченко © (10.11.06 15:40) [58]
>> Сервер на той же машине, что и приложение?
>На ошибку это не влияет.

Будет время на выходных, провёрю. Т.к. есть сомнения, что не влияет...:)

А вообще-то, хотя и несколько offtop, возникло ощущение, что подобные проблемы - суть последствий сражения EК vs ИК (естественные vs искусственные ключи).
Такое раздутие таблиц вполне объяснимо использованием естественных ключей.

Напомню, был тут как-то такой холивар и именно Игорь отстаивал целесообразность ЕК, я же приводил разные аргументы в пользу ИК.
Разумеется дело не ограничилось мной и Игорем, всяк влил свою дозу яда в ухо противника.:))

Посмотрел статистику по одному из своих последних проектов
8000 записей в день
Средняя длина записи - 120 байт
т.е 1M в день и примерно 300М в год
Соответственно - 2 млн записей в год.

Проект честно отработал 1 год.

Все исключительно на искусственных ключах.

На восьмом месяце беременности проект в течение одного для всех 15 филиалов и центрального офиса был плавно выведен из СУБД DBISAM и переведен на FB.
Простой - 1 час на рабочее место.

> ANB © (10.11.06 16:38) [66]

> Основное их преимущество - возможность доставать ID до вставки.

Не поверишь, но даже без такой возможности, все возможно.

> Не поверишь, но даже без такой возможности, все возможно.

Могет быть. Но в мс скл стандартно ID после вставки вытаскивают. Да еще и извращенно. А для доставания до вставки - нужно уже еще сильнее извращаться (наверное).

ANB © (10.11.06 17:05) [70]

Если кто не знаком с СУБД DBISAM - напомню: создавалась как F/S ISAM, затем выросла в C/S.
Последней я практически не пользовался, т.к. имел лицензию от www.elevatesoftware.com на распространение исключительно F/S.
Там много чего вкусного по состоянию на 98 год было, BDE и не снилось такое.
Например, почти полное покрытие SQL-92.

А автоинкремент не приемлю в принципе, хотя она и позволяет.

Поэтому была сделана система конкурентной вставки очередной записи в многопользовательской среде.
Никто же не возражает, что в сети Ethernet принципиально заложены коллизии при доступе ?

Вот так и там. Попытка получить доступ к max(id), корректная отработка исключений.
По такой технологии было выполнено достаточно проектов, чтобы судить о приемлимости такого решения.

Jeer © (10.11.06 17:02) [68]

Вот чем мне нравится этот сайт - это посетителями. Честное слово. За те четыре года, что я здесь нахожусь, я успел познакомиться с таким количеством уважаемых мною людей, с которым в реальной жизни вряд ли успел бы пообщаться на столь разнообразные темы.

Сергей, ну скажи мне ради Аллаха всемилосердного, причем тут искусственные или естественные ключи ? Я в одном из постов написал, как выглядит запрос, никаких ключей там в принципе не используется, проблема не на сервере, проблема на клиентской стороне, не получилось у BDE справиться с таким объемом данных, данная ошибка присутствует в гугле, куда я посмотрел прежде чем задавать вопрос на этом сайте, разумеется, я испробовал все советы, которые нашел по данному вопросу, ни один не помог (хотя, там и не было обещано, что они помогут во всех ситуациях).

Я уже писал, что я не собираюсь разделять запрос на порции, в данном случае эта моя принципиальная позиция. Ключи к этой позиции не имеют никакого отношения.
Я НЕ ВИДЕЛ В ДОКУМЕНТАЦИИ К BDE, IBX НИ ОДНОЙ ФРАЗЫ О ТОМ, ЧТО РЕЗУЛЬТАТЫ ПРОИЗВОЛЬНОГО ЗАПРОСА НЕ МОГУТ БЫТЬ ПРОЧИТАНЫ ИЗ-ЗА КАКИХ-ТО ОГРАНИЧЕНИЙ.

Может, я невнимательно читал, в таком случае просьба ткнуть меня носом в документацию, я с благодарностью приму пинок и пойму, что зря ориентировался на BDE с самого начала.

> Попытка получить доступ к max(id),

Я так извращался на клиппере. Не сказать, чтобы я был в восторге от этого. Посему, когда начал работать с ораклом и узнал про сиквенсы, меня это сильно порадовало и к клипперу я более не вертаюсь :)

Jeer © (10.11.06 17:02) [68]

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

> Игорь Шевченко © (10.11.06 17:23) [72]

dbExpress-овский компонент попробовал, который я тестил ?
Совет - блобы тянуть по одному и тут же чистить.

> естественные ключи я до сих пор продолжаю отстаивать, потому
> что всякий autoincrement есть зло,

автоинкремент - зло, хоть и небольшое.
естественные ключи - тоже зло. намного большее. связки по ним делать низзя.
Вот одного не понял - почему ЕК - это хорошо, из-за того, что автоинкремент - плохо ?

Игорь Шевченко © (10.11.06 17:23) [72]

Ара, говорим -да:)))

>Я НЕ ВИДЕЛ В ДОКУМЕНТАЦИИ К BDE
..
> РЕЗУЛЬТАТЫ ПРОИЗВОЛЬНОГО ЗАПРОСА

А экстраполировать ограничения BDE на естественное и такое же ограничение временных таблиц ?

Игорь, да чес слово - тоже пытаюсь помочь тебе.
Что ж я от нефиг делать перелопачиваю уйму байтов на диске ?
Самому стало интересно, кое-какие "просветы" возникают, но до выяснения
обстоятельств умолчу.

Но попутно "всплывают образы, как у истинного левши" :)))

> потому что всякий autoincrement есть зло,

Согласен на все сто:)

ANB © (10.11.06 17:26) [75]
Jeer © (10.11.06 17:30) [77]

Я вообще-то проблему решил :) Об чем писал в посте [45].

Вкратце все-таки попытаюсь озвучить проблему: есть база данных с несовсем идеальной структурой. Ищется наиболее быстрый способ преобразования ейных данных в почти идеальную структуру. Данных много.

Преобразование должно запустить один раз, отработать и забыть.

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

Решение "в лоб" (чтение согласно структуры исходной базы, преобразование в целевую структуру) работает, хотелось бы сравнить быстродействие остальных способов, например выгрузку с минимальными преобразованиями в набор плоских файлов и запуск штатного загрузчика СУБД, и т.п.

> например выгрузку с минимальными преобразованиями в набор
> плоских файлов и запуск штатного загрузчика СУБД

граблей не оберешься. Проверено по опыту работы с оракловым лоадером.

Игорь Шевченко © (10.11.06 17:43) [79]

Решил - так решил.:)
По крайней мере я буду учитывать в дальнейшем такие проблемы, хотя и не нарывался в лоб, поскольку изначальная "сверхоптимизация" базы при ее проектировании - задача для меня всегда первостепенная.

В общем:
"Как прыгнешь, так и приземлишься". (С)

ANB © (10.11.06 17:46) [80]

Странно. По опыту работы с оракловым лоадером проблем не наблюдал, не надеюсь их наблюдать и в дальнейшем.

Jeer © (10.11.06 17:51) [81]

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

Как показывает опыт, любая сверхоптимизированная схема базы данных менее чем за десять лет перестает быть таковой.

> По опыту работы с оракловым лоадером проблем не наблюдал,
> не надеюсь их наблюдать и в дальнейшем.

Это если суперакуратно все сделать. Малейшие неаккуратные изменения - и приехали. Причем глюки выловишь уже при работе с БД - например порезались символы.

> Игорь Шевченко © (10.11.06 18:04) [82]

> менее чем за десять лет

Игорь, окстись - какие десять лет:))))
Кушать хочется и им и нам.

Важно направить поток сознания и зависящие от него финансы в очень правильное русло - ни месяца без update:))

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

В общем, дела нас переживут:))

ANB © (10.11.06 18:08) [83]

Вот почему любые телодвижения за пределы родной для СУБД базы давно выполняю исключительно собственными ручками с дополнением н-го количества кода на чем придется и что эффективно на данный момент.

> Jeer (10.11.2006 17:02:08) [68]

А вывод?
У тебя искуственные ключи, тогда согласно элементарной логике, выходит что их надо выбросить, или у меня неполадки с логикой?

Anatoly Podgoretsky © (10.11.06 20:28) [86]

> А вывод?

Вывод простой - ни на одном из выполненных мной проектов, где использовались ИК, число полей и длина записи не достигали и 1/10 того, что обсуждалось по сабжу, соответственно и проблем с такими объемам не возникало.

> Anatoly Podgoretsky © (13.11.06 10:23) [88]

Главное - чтобы не физическая.:)
Ладно, замнем-с тему.
Каждый уяснил что-то важное для себя и то - хлеб.

EDBEngineError Найти похожие ветки