EDBEngineError

← →
Игорь Шевченко © (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]

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

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

← →
Anatoly Podgoretsky © (2006-11-10 16:28) [63]

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

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

← →
ANB © (2006-11-10 16:32) [64]

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

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

← →
Anatoly Podgoretsky © (2006-11-10 16:36) [65]

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

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

← →
ANB © (2006-11-10 16:38) [66]

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

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

← →
Johnmen © (2006-11-10 16:41) [67]

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

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

← →
Jeer © (2006-11-10 17:02) [68]

А вообще-то, хотя и несколько 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].

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

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

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

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

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

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

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