dbf в fdb
dbf в fdb
На работе вовсю используются фокс-прошные базы (*.dbf). Подскажите как можно dbf таблицу перевести в таблицу в базе Firebird.
Re: dbf в fdb
1 создать структуру таблицы в FBUnsiker писал(а): На работе вовсю используются фокс-прошные базы (*.dbf). Подскажите как можно dbf таблицу перевести в таблицу в базе Firebird.
2 перегнать данные, например IBPump или свое наваять, если желание и время есть
-
Kotъ-Begemotъ
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Re: dbf в fdb
Зачем что-то создавать? Pump сам это прекрасно делает...stix-s писал(а):1 создать структуру таблицы в FBUnsiker писал(а): На работе вовсю используются фокс-прошные базы (*.dbf). Подскажите как можно dbf таблицу перевести в таблицу в базе Firebird.
2 перегнать данные, например IBPump или свое наваять, если желание и время есть
По делу, думаю что поставить IBExpert и скачать IB Data Pump в качестве плагина к нему. Я Paradox'овскю базу на пробу перегнал недавно, прошло. Есть правда нюансы с которыми надо разбираться, но в целом сработало нормально.
Re: dbf в fdb
Нееее, я лично предпочитаю сам контролировать процесс, так сказать ......., дабы потом ньюансы не разгребатьKotъ-Begemotъ писал(а): Зачем что-то создавать? Pump сам это прекрасно делает...
Есть правда нюансы с которыми надо разбираться, но в целом сработало нормально.
но это я так, к слову, но если придется данные из Excel перегонять - будь бдителен, у него (Excel) свое понятие о формате данных
да, с Access проблем меньше было, поскольку в свое время пришлось именно в Access таблицы из Excel импортироватьSlavik писал(а):Можно ещё Access'омUnsiker писал(а):Ексель в даном случае не уместен, так как база бльшая, порядка 100,000 записей. Попробую пимпом.. Copy-Paste. Я так пару раз около 30 тыс. записей перегонял единоразово
.
Топик устарел, но у меня такой же вопрос.
В книге ХБ по Firebird сказано что перевод БД из "настольной БД" в SQL сервер часто сопровождается длительными операциями, и, в конце концов, голову программиста приносят юзерам на блюде.
Всё ещё зависит от того КАКАЯ таблица переносится в SQL.
К примеру мой вариант. За пол года накапливается около 90 тысяч строк.
Колонки:
1: Документ
2: Форма печати
3: Дата печати
4: Время печати
5: Пользователь
6: Компьютер
Т.к. DBF это одна таблица, а SQL это целый набор взаимосвязанных таблиц... нужно решить КАК переносить колонки 2,5,6.
Иначе получатся колонки с повторяющимися длинными значениями
2: Всего 3 формы печати, названия форм длиной до 15 символов.
5: Имена пользователей. 20 разновидностей юзеров, по 15 символов.
6: Компьютеры. 2-3 типа значения, строка 10 символов.
Нужно завести домены?
PRN_FORMS, 1C_USERS, COMPUTERS.
Я читал в книжке ХБ, там сказано что домены это типы данных.
Уместны ли они в моём случае - не знаю...
В книге ХБ по Firebird сказано что перевод БД из "настольной БД" в SQL сервер часто сопровождается длительными операциями, и, в конце концов, голову программиста приносят юзерам на блюде.
Всё ещё зависит от того КАКАЯ таблица переносится в SQL.
К примеру мой вариант. За пол года накапливается около 90 тысяч строк.
Колонки:
1: Документ
2: Форма печати
3: Дата печати
4: Время печати
5: Пользователь
6: Компьютер
Т.к. DBF это одна таблица, а SQL это целый набор взаимосвязанных таблиц... нужно решить КАК переносить колонки 2,5,6.
Иначе получатся колонки с повторяющимися длинными значениями
2: Всего 3 формы печати, названия форм длиной до 15 символов.
5: Имена пользователей. 20 разновидностей юзеров, по 15 символов.
6: Компьютеры. 2-3 типа значения, строка 10 символов.
Нужно завести домены?
PRN_FORMS, 1C_USERS, COMPUTERS.
Я читал в книжке ХБ, там сказано что домены это типы данных.
Уместны ли они в моём случае - не знаю...
убиться можно, какой страшный объем.За пол года накапливается около 90 тысяч строк.
эти 90 тысяч импортируются максимум за 10 минут, даже при плохо написанном коде импорта.
вообще-то, у человека, который проектировал БД, такого вопроса не возникает.нужно решить КАК переносить колонки 2,5,6.
а что, домены сами импортируют данные?Нужно завести домены?
как я понял, у вас и базы-то еще нет. Сделайте базу сначала. импортом потом будете заниматься.
1-С чего ты решил, что дбф-одна таблица? сколь захочешь, столь и сделаешь, все зависит от структуры твоей БД, то, что в дбф каждая таблица - отдельный файл, еще не означает, что она может быть только однаasmator писал(а):Топик устарел, но у меня такой же вопрос.
В книге ХБ по Firebird сказано что перевод БД из "настольной БД" в SQL сервер часто сопровождается длительными операциями, и, в конце концов, голову программиста приносят юзерам на блюде.
Всё ещё зависит от того КАКАЯ таблица переноситься в SQL.
К примеру мой вариант. За пол года накапливается около 90 тысяч строк.
Колонки:
1: Документ
2: Форма печати
3: Дата печати
4: Время печати
5: Пользователь
6: Компьютер
Т.к. DBF это одна таблица, а SQL это целый набор взаимосвязанных таблиц... нужно решить КАК переносить колонки 2,5,6.
Иначе получатся колонки с повторяющимися длинными значениями
2: Всего 3 формы печати, названия форм длиной до 15 символов.
5: Имена пользователей. 20 разновидностей юзеров, по 15 символов.
6: Компьютеры. 2-3 типа значения, строка 10 символов.
Нужно завести домены?
PRN_FORMS, 1C_USERS, COMPUTERS.
Я читал в книжке ХБ, там сказано что домены это типы данных.
Уместны ли они в моём случае - не знаю...
Количество строк повлияет только на время перекачки
хоть миллион переноси2-при переводе на SQL -сервер тебе решать, изменится у тебя структура БД или останется прежней, конечно при изменении структуры придется поломать голову, как старые данные в новую структуру запихать
3-домены для облегчения твоей жизни, дабы не приходилось однотипные поля (типа varchar(45)) каждый раз заново описывать, а просто создать домен и на его основе поля однотипные
re: asmator
По моему опыту, если необходимо запихнуть в FireBird данные из ДБФ, да еще и переконвертировать, то лучше временно создать таблицы DBF_<имя дбф-файла> с прежней структурой, загрузить в них оригинал (тем же DataPump) и далее работать уже с ними, подгоняя под новую структуру.