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

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

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

Программная перекачка из DBF в MSSQL [D6, MSSQL, dBase, FoxPro]

Страницы: 1 2 3 >
kivadim © (2005-05-18 09:44:00)
Есть таблички DBF-ки, которые имеют одинаковые структуры и данные из которых нужно перекачивать в таблицу на MSSQL сервере.
Перекачку в проге делаю следующим образом:
procedure TForm1.TransferData(TName: string); var i: integer; begin flDM.DBF_Query.Close; flDM.DBF_Query.SQL.Clear; flDM.DBF_Query.SQL.Text:='select * FROM '+TName+' '; flDM.DBF_Query.Open; flDM.MSSQL_Query.Close; flDM.MSSQL_Query.SQL.Clear; flDM.MSSQL_Query.SQL.Text:='insert into MSTable values('+ ':FL000, :FL00_1_1, :FL00_1_2, :FL01, :FL01_A, :FL02_1, :FL02_2, '+ ':FL03, :FL04, :FL05, :FL11, :FL12, :FL13, :FL15, :FL16, :FL17, :FL30, :FL31, '+ ':FL32_1, :FL32_2, :FL33, :FL34, :FL35_1, :FL35_2, :FL35_3, :FL35_4, :FL41_1, '+ ':FL41_2, :FL45_1, :FL45_2, :FL45_3, :FL45_4, :FL42, :FL50, :FL51, :FL52_1, '+ ':FL52_2, :FL52_3, :FL53, :FL61, :FL61_1, :FL61_2, :FL62, :FL63_1, :FL63_2, '+ ':FL71_1, :FL71_2, :FL00_3, :FL00_4, :FL00_5, :FL00_6, :FL00_7, :FL00_8) '; while not flDM.DBF_Query.Eof do begin for i:=0 to 52 do begin flDM.MSSQL_Query.Parameters[i].Value:=flDM.DBF_Query.Fields[i].AsVariant; end; flDM.MSSQL_Query.ExecSQL; flDM.DBF_Query.Next; end; flDM.DBF_Query.Close; end;

но работает довольно медленно, так например ~35000 записей перекачиваются порядка 5-7 минут.
Можно ли записать гетерогенный запрос в котром участвовали бы таблица .dbf и таблица mssql?
Ну или хотябы как увеличить быстродействие существующего решения?

Anatoly Podgoretsky (2005-06-07 21:01:00) [1]
В документации по данному провайдеру. Поиском надеюсь умеешь пользоваться.

kivadim (2005-06-07 18:10:00) [2]
>Anatoly Podgoretsky © (07.06.05 17:01) [56]

а где можно посмотреть настройки Microsoft OLE DB Provider for Visual FoxPro?

Anatoly Podgoretsky (2005-06-07 17:01:00) [3]
Смотри настройки провайдера

kivadim (2005-06-07 16:57:00) [4]
все заработало через
SELECT * FROM OPENROWSET('VFPOLEDB','D:\dbf';'';'',select * from 878_050501_050504.dbf]')
но в некоторых записях МЕМО-поля есть данные на русском и они при перекачке отображаются как каракули.

Нашел способ как это обойти, а именно
SELECT * FROM OPENROWSET('VFPOLEDB','D:\dbf';'';'',select fl1, fl2, ..., fl62 cpconvert(866, 1251, fl62) as fl62from 878_050501_050504.dbf]')
но это только для строк длинной <= 255 символов, т.к. если строка в МЕМО-поле > 255, то выдается ошибка:

Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'VFPOLEDB' reported an error.
[OLE/DB provider returned message: String is too long to fit.]
OLE DB error trace [OLE/DB Provider 'VFPOLEDB' ICommandText::Execute returned 0x80004005: ].

Как конвертнуть строки более 255 символов?

Anatoly Podgoretsky (2005-06-02 20:40:00) [5]
Ну так он в Extended Properties явно указал dBase 5.0, он пытается найти *.dbt

Понимает и перестраивает FoxPro а не Дельфи и БДЕ или ODBC

sniknik (2005-06-02 20:10:00) [6]
Anatoly Podgoretsky © (02.06.05 19:11) [52]
> Какой к черту .fpt
ну до 2.5 (6-?) DOS версии поддерживается, и даже индексы воспринимает, перестраивает... (насколько помню, давно тестил. надо перепроверить)

kivadim (02.06.05 18:55) [51]
> хотя после появления всех этих проблем с именами на серверный комп установили Jet 4.0 Service Pack 8 (SP8) for Windows Server 2003
> (KB829558).
а вот про это забудь, обновлением не решить. с версии 3.5 jet не поддерживает fox-а, то что осталось это по "забывчивости" программистов мелкософта, забыли "вынуть". ;о)) (но скорее по причинам совместимости для уже написанного)
попробуй через ODBC VFP (вижуал фокспро) драйвер тоже самое, там тебе ссылку гдето давали в ней пример есть для него, найдеш.

Anatoly Podgoretsky (2005-06-02 19:11:00) [7]
kivadim (02.06.05 18:55) [51]
select * from OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'dBase 5.0;DATABASE=D:\dbf', 'Select * from [868_05~1.DBF]')Какой к черту .fpt

kivadim (2005-06-02 18:55:00) [8]
>> Anatoly Podgoretsky © (02.06.05 16:40) [49]
Вы правы, в общем случае не у всех таблиц есть .fpt файл

Но даже если просто скопировать в пустой каталог с коротким именем просто одну пару *.dbf и *.fpt, то запрос вида (с реальным путем)
select * from OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'dBase 5.0;DATABASE=D:\dbf', 'Select * from [868_05~1.DBF]')
выдаст такую же ошибку как и в [38], как и выдаст такую же ошибку , если скинуть пару в каталог D:\dbf_folder и оттуда запустить запрос.

а если просто один файл *.dbf без *.fpt, то запрос срабатывает (с коротким именем файла) хоть из каталога
D:\dbf, хоть из D:\dbf_folder, т.к. что вроде бы длина имени каталога не является причиной ошибки.

Т.е. вывод: Запрос рушиться не когда пути длинные, а только когда идет обращение к таблице с файлом .fpt, а значит возможно как sniknik сказал "Fox оказазался более старшей версии чем от которого jet мемо поля понимает", хотя после появления всех этих проблем с именами на серверный комп установили Jet 4.0 Service Pack 8 (SP8) for Windows Server 2003 (KB829558).

sniknik (2005-06-02 18:28:00) [9]
ну почему не учитываю? именно поэтому и говорил что запись должна быть > "строго парами" и без пропусков. ([41])

Anatoly Podgoretsky (2005-06-02 16:40:00) [10]
sniknik © (02.06.05 13:27) [45]
Думаю не учитываешь, что не у всех таблиц есть .fpt файл, поэтому пары будут разбиты. Для условия 703_05~n.*

sniknik (2005-06-02 15:50:00) [11]
> это из-за того что каждый архив распаковывается в создавыемый каталог по имени архива, например:
про каталог это ты хорошо напомнил... посчитай на досуге символы в нем.

> и вообще если даже я вручную переименую пару 703_050412_050412.DBF и 703_050412_050412.FPT например в test.dbf и test.fpt
еше и каталог переименуй в D:\Dbf\ и если будет ошибка то дело не в этом, а например в том что Fox оказазался более старшей версии чем от которого jet мемо поля понимает.

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

> И еще обнаружил непонятное поведение MS сервера
вроде бы говорили что от него в этом случае как раз ничего не зависит. (???) мало ли чего ты там переставлял/менял.

> И что делать пока не придумал...
думай, про все уже говорилось. по второму одно и тоже обсуждать не хочется.

p.s. фантазия конечно дело хорошее, но для точных данных нужна уверенность, а посмотреть так понимаю ты не хочеш. (вернее даже не самому посмотреть, а нам обьяснить, при каких конкретно коротких именах рушится, и не тех что ты придумал(скорее всего) а тех что получил от системы)

kivadim (2005-06-02 14:44:00) [12]
И еще обнаружил непонятное поведение MS сервера, а именно:
Позавчера поставил сервак на третий комп по Windows2000(потестить на нем) и все работало как с длинными именами так и с короткими. Однако через 1 день на нем так же как и на серверном компе перестало воспринимать длинные имена. А сегодня, остановив MS сервак не третьем компе и запустив ее занового обнаружил что снова воспринимаюся длинные имена, однако на серверном компе такой перезапуск MS-a не исправил дела с длинными именами.

Вот таки непонятки... :))

kivadim (2005-06-02 14:10:00) [13]
вообще у меня алгоритм следующий:
пользователь указывает каталог с архивами *.rar в каждом из которых находится пара файлов dbf и fpt.
Прога последовательно распаковывает все архивы каталога в другой каталог на сервере и потом последовательно на каждую dbf-ку запукает запрос по перекачке данных в MS, так что последовательность возрастающих цифр в коротких именах должна наблюдаться.

команда DIR выдает полные имена

>> иначе чем обьяснить попытку удалять рабочий каталог?
это из-за того что каждый архив распаковывается в создавыемый каталог по имени архива, например:
D:\dbf_folder\703_050412_050412\703_050412_050412.dbf
703_050412_050412.fpt
и вот тут сами файлы удаляются после отработки, а каталог D:\dbf_folder\703_050412_050412 нет т.к. занят сервером.

и вообще если даже я вручную переименую пару 703_050412_050412.DBF и 703_050412_050412.FPT например в test.dbf и test.fpt, то все равно выдается ошибка из поста [38]. Т.е. не находит в DBF-ке
МЕМО поле, т.к. не находит файл fpt. Я так пока думаю.
И что делать пока не придумал...

sniknik (2005-06-02 13:27:00) [14]
проверить надо, чтобы убедится что в этом дело.

> Но можно не проверять и даже не пытаться парами копировать, нет ни какой гарантии.
начав с чистой директории с большой вероятностью получим последовательно возрастающие цифры в коротких именах.
главное пропусков не делать и не удалять один из пары после (вся линейка выше "сдвинется") и т.д. (х.з. где еще "напоремся") в общем работать вполне можно, если осторожно. ;)
проще конечно переименовать файлы до работы (как еще в [22] говорил), все одно файлы временные (иначе чем обьяснить попытку удалять рабочий каталог?)

Anatoly Podgoretsky (2005-06-02 12:31:00) [15]
sniknik © (02.06.05 12:00) [41]
Для проверки достаточно обычной команды DIR
Но можно не проверять и даже не пытаться парами копировать, нет ни какой гарантии.

Anatoly Podgoretsky (2005-06-02 12:30:00) [16]
sniknik © (02.06.05 12:05) [42]
Берешь пример с правильных людей :-)

sniknik (2005-06-02 12:05:00) [17]
везде где в [41] fpf читать fpt. руки у меня чтото "окривели" ;о).

sniknik (2005-06-02 12:00:00) [18]
возьми старый (добрый ;о)) NC, dos-овский, и посмотри в нем на имена .dbf & .fpt тех которые не находит. и удивишся ты (возможно) ;о)) т.к. у тебя скорее всего будет не 703_05~1.FPT а 703_05~2.FPT или 3 и тд.
чтобы имена совпадали копирование надо производить строго парами т.е. dbf и сразу fpf а не, сначала все dbf а после все fpf. и без пропусков одного из них, большая вероятность что не совпадут.

можеш смотреть не нортоном(трудно наверное счас найти ;), просто проверить имя fpf тем же способом что короткое имя dbf-а получаеш.

и кстати fpf это не фоксовый мемо файл? а подключение к dBase. хотя jet ранние версии фокса понимает (как и BDE), так что в принципе неважно.

Anatoly Podgoretsky (2005-06-02 11:52:00) [19]
kivadim (02.06.05 11:20) [38]
Надеюсь последний вопрос с моей стороны на эту тему.. :))

До сих пор таблицы dbf состояли из одного файла, например:325_050214_050214.dbf
Теперь же приходят таблицы dbf, состоящие из двух файлов, например: 703_050412_050412.DBF и 703_050412_050412.FPT, т.е. файл с полем МЕМО.
Так вот при исполнении запроса, используя короткое имя

select count(*) from OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'dBase 5.0;DATABASE=D:\dbf_folder',
'Select * from [703_05~1.DBF]')

Короткое имя одного файла нельзя применять для короткого имени другого файла. Я думаю, что когда тебе говорили про короткое имя, то имели в виду формат 8.3, а не двойственность природы FAT

Т.е. я предполагаю что, используя короткое имя файла DBF, сервер не находит файл 703_050412_050412.FPT

Ему не зачем искать это имя, когда ты явно сказал искать 703_05~1.FPT, а такого файла или нет или система не намерена искать по короткому имени FAT, что монопенисно.

kivadim (2005-06-02 11:24:00) [20]
забыл сказать что структура всех DBF таблиц одинакова, просто в некоторых одно поле типа МЕМО а в других типа CHARACTER

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

Наверх

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