Программная перекачка из DBF в MSSQL

← →
Anatoly Podgoretsky © (2005-06-02 11:52) [40]

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, что монопенисно.

← →
sniknik © (2005-06-02 12:00) [41]

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

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

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

← →
sniknik © (2005-06-02 12:05) [42]

везде где в [41] fpf читать fpt. руки у меня чтото "окривели" ;о).

← →
Anatoly Podgoretsky © (2005-06-02 12:30) [43]

sniknik © (02.06.05 12:05) [42]
Берешь пример с правильных людей :-)

← →
Anatoly Podgoretsky © (2005-06-02 12:31) [44]

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

← →
sniknik © (2005-06-02 13:27) [45]

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

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

← →
kivadim (2005-06-02 14:10) [46]

вообще у меня алгоритм следующий:
пользователь указывает каталог с архивами *.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. Я так пока думаю.
И что делать пока не придумал...

← →
kivadim (2005-06-02 14:44) [47]

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

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

← →
sniknik © (2005-06-02 15:50) [48]

> это из-за того что каждый архив распаковывается в создавыемый каталог по имени архива, например:
про каталог это ты хорошо напомнил... посчитай на досуге символы в нем.

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

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

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

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

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

← →
Anatoly Podgoretsky © (2005-06-02 16:40) [49]

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

← →
sniknik © (2005-06-02 18:28) [50]

ну почему не учитываю? именно поэтому и говорил что запись должна быть > "строго парами" и без пропусков. ([41])

← →
kivadim (2005-06-02 18:55) [51]

>> 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).

← →
Anatoly Podgoretsky © (2005-06-02 19:11) [52]

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

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 (вижуал фокспро) драйвер тоже самое, там тебе ссылку гдето давали в ней пример есть для него, найдеш.

Ну так он в Extended Properties явно указал dBase 5.0, он пытается найти *.dbt

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

← →
kivadim (2005-06-07 16:57) [55]

все заработало через
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 fl62 from 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 символов?

Смотри настройки провайдера

← →
kivadim (2005-06-07 18:10) [57]

>Anatoly Podgoretsky © (07.06.05 17:01) [56]

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

В документации по данному провайдеру. Поиском надеюсь умеешь пользоваться.

Программная перекачка из DBF в MSSQL Найти похожие ветки