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

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

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

EDBEngineError

Страницы: < 1 2 3 4 5 >
Climber © (2006-10-09 06:37:00)
Где фиксить EDBEngineError "Temporary table resourse limit"?.
Спасибо.

Jeer (2006-11-10 17:03:00) [21]

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

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

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

Jeer (2006-11-10 17:02:00) [22]
А вообще-то, хотя и несколько offtop, возникло ощущение, что подобные проблемы - суть последствий сражения EК vs ИК (естественные vs искусственные ключи).
Такое раздутие таблиц вполне объяснимо использованием естественных ключей.

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

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

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

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

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

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

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

ANB (2006-11-10 16:38:00) [24]

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

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

Anatoly Podgoretsky (2006-11-10 16:36:00) [25]
> ANB (10.11.2006 16:32:04) [64]

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

ANB (2006-11-10 16:32:00) [26]

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

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

Anatoly Podgoretsky (2006-11-10 16:28:00) [27]
> ANB (10.11.2006 16:25:02) [62]

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

ANB (2006-11-10 16:25:00) [28]

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

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

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

Anatoly Podgoretsky (2006-11-10 16:12:00) [29]
> Jeer (10.11.2006 15:56:00) [60]

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

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

Jeer (2006-11-10 15:56:00) [30]
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 15:41:00) [31]
> Jeer (10.11.2006 15:09:56) [56]

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

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

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

Игорь Шевченко (2006-11-10 15:40:00) [32]
Johnmen © (10.11.06 15:28) [57]

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

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

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

Johnmen (2006-11-10 15:28:00) [33]

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

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

Jeer (2006-11-10 15:09:00) [34]
Anatoly Podgoretsky © (10.11.06 15:00) [55]

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

Anatoly Podgoretsky (2006-11-10 15:00:00) [35]
> Jeer (10.11.2006 14:51:54) [54]

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

Jeer (2006-11-10 14:51:00) [36]
Игорь Шевченко © (10.11.06 14:42) [53]

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

Игорь Шевченко (2006-11-10 14:42:00) [37]
Johnmen © (09.11.06 22:51) [50]

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

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

Jeer © (10.11.06 10:34) [52]

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

Jeer (2006-11-10 10:34:00) [38]
Игорь Шевченко © (09.11.06 22:35) [49]

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

Jeer (2006-11-10 10:32:00) [39]
Игорь Шевченко © (09.11.06 22:35) [49]

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

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

Johnmen (2006-11-09 22:51:00) [40]

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

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

Страницы: < 1 2 3 4 5 >

Наверх

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