Мастера 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?
Ну или хотябы как увеличить быстродействие существующего решения?

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

До сих пор таблицы 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]')
выдается ошибка:

Server: Msg 7357, Level 16, State 2, Line 1
Could not process object 'Select * from [703_05~1.DBF]'. The OLE DB provider 'Microsoft.Jet.OLEDB.4.0' indicates that the object has no columns.
OLE DB error trace [Non-interface error: OLE DB provider unable to process object, since the object has no columnsProviderName='Microsoft.Jet.OLEDB.4.0', Query=Select * from [703_05~1.DBF]'].

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

Как можно разрулить и эту ситуацию?

sniknik (2005-06-01 16:35:00) [22]
не получится, это с BDE тянется, том тоже пока сессию не закроеш/из программы не выйдеш каталог не удаляется. а тут не ты сессию открываеш а jet, а он не выгружается сразу на случай следующих обрашений (так быстрее). попробуй обойтись без временного каталога, который надо после удалять... (можно системный tmp использовать например)

kivadim (2005-06-01 16:11:00) [23]
>> Anatoly Podgoretsky © (01.06.05 15:57) [35]

Каталог пуст на 100%.

> Пытать предварительно сделать другую папку текущей

это как? другой запрос c др. каталогом?

Anatoly Podgoretsky (2005-06-01 15:57:00) [24]
Каталог является текущим и не пуст. Пытать предварительно сделать другую папку текущей

kivadim (2005-06-01 15:50:00) [25]
Благодарю всех за помощь.
Но заметил еще один неприятный эффект от использования такого рода запроса:
insert into MS_table select select * from OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'dBase 5.0;DATABASE=D:\dbf_folder', 'Select * from [749_050320_050418]')

а именно после отработки такого запроса не могу ни программно, ни вручную удалить например каталог D:\dbf_folder, участвовавший в запросе. Т.к. получается что он занят в работе MSSQL сервера, хотя запрос отработал. Удалить каталог удается лишь перезапустив MSSQL сервер.

Как все же удалить папку не перезапуская сервер?

Anatoly Podgoretsky (2005-05-30 19:14:00) [26]
kivadim (30.05.05 17:20) [31]
OLE/DB provider returned message: [Microsoft][ ODBCdBase Driver] The Microsoft Jetdatabase engine could not find the object

Вот это ты же привел? А Jet работает через БДЕ, у тебя очень длинная цепочка драйверов, с ограничениями на каждом звене.

sniknik (2005-05-30 17:56:00) [27]
> Думаю это не причина, т.к. и через ODBC dBase Driver таже фишка
а ты внимательнее прочитай чтотебе ошибку выдает, с ODBC.

> BDE стоит на обоих машинах, хотя причем тут он...?
при том же, jet в свою очередь тоже передает управление дальше, в некоторых случаях.

kivadim (2005-05-30 17:20:00) [28]
>> возможно версия jet разная.
Думаю это не причина, т.к. и через ODBC dBase Driver таже фишка

SELECT * FROM
OPENROWSET('MSDASQL',
'Driver={Microsoft dBase Driver (*.dbf)};DBQ=D:\Users\DAO\mid',
'Select * from 703_050320_050418.DBF')

BDE стоит на обоих машинах, хотя причем тут он...?

sniknik (2005-05-30 17:11:00) [29]
или BDE в одном месте стоит а на севере нет. вот режимы и различаются. проще делай так, как будто нигде не работает...

sniknik (2005-05-30 17:07:00) [30]
> и теперь остается вопрос почему раньше удаленный сервак работал с длинными именами, а локальный до сих пор без проблем работает?
возможно версия jet разная.

kivadim (2005-05-30 16:58:00) [31]
>> с такими именами? не верю! (© Станиславский)

действительно работало с такими именами. попробовал имена до 8 символов и работает. и теперь остается вопрос почему раньше удаленный сервак работал с длинными именами, а локальный до сих пор без проблем работает?

Хотя возможно причина в том что серверная машина работает под управлением Windows Server 2003, а моя локальная под XP?

>> MOA © (30.05.05 16:42) [27]
если запрос выполняет удаленный сервер то соответственно БДФ-ка находится на локальном диске серверной машины.

MOA (2005-05-30 16:42:00) [32]
D - это с точки зрения удалённого сервера - его локальный диск?

sniknik (2005-05-30 16:35:00) [33]
> Буквально в пятницу все работало без проблем, а сегодня на тебе...
с такими именами? не верю! (© Станиславский)
должны быть короче. используются DOS соглашения имен, в твоем случае ищется такое путь D:\DBF_FO~1\ имя файла 730_05~1 dbf. при условии что файл один в папке либо первый в списке (!!!!!) если не первый не поможет (в конце будет 2/3/и т.д.), даже если после удалить остальные. (точную информацию об коротком имени дает уже приводившаяся процедура)
либо переименовывать в то что совпадает с полным именем (длинное = короткое). опять уже говорилось. (игнор? я у тебя в черном списке? скажи, я отстану)

kivadim (2005-05-30 16:21:00) [34]
>> Anatoly Podgoretsky © (30.05.05 16:08) [24]

:)) Да я понимаю что он пишет. В том то и дело что таблица находиться в каталоге и путь прописан правильно, т.к. если для проверки переименовать ее, то все работает. На локальном же сервере все работает с любым именем, так что это проблема сервера и как ее искоренить я не понимаю. Буквально в пятницу все работало без проблем, а сегодня на тебе...

Anatoly Podgoretsky (2005-05-30 16:08:00) [35]
Ну говорит же, что не может найти указаную таблицу и предлагает проверить правильность пути.

kivadim (2005-05-30 16:02:00) [36]
to Nikolay M. © (30.05.05 15:35) [21]

нет такое же поведение, на локальном сервере работает, а на удаленном на запрос
SELECT * FROM OPENROWSET('MSDASQL', 'Driver={Microsoft dBase Driver (*.dbf)};DBQ=D:\dbf_folder\', 'Select * from [730_050320_050418]')

выдает ошибку

Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [Microsoft][ODBC dBase Driver] The Microsoft Jet database engine could not find the object '730_050320_050418'. Make sure the object exists and that you spell its name and the path name correctly.]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IColumnsInfo::GetColumnsInfo returned 0x80004005: ].

sniknik (2005-05-30 15:36:00) [37]
переименовывать надо по правилам наименования DOS файлов (не более 8 символов, и без всяких недопустимых в именах файлов/директорий знаков), либо можно получить короткое имя файла от системы (там уже все по "правильному") и давать в запрос уже эти имена базы/таблици. (получить с помощью GetShortPathName)

Nikolay M. (2005-05-30 15:35:00) [38]
http://www.sql.ru/forum/actualthread.aspx?tid=180672#1524673

kivadim (2005-05-30 15:21:00) [39]
Надо же возникла какая-то непонятная ошибка.

На локальном MSSQL сервере все работает нормально, а на удаленном MSSQL выдает ошибку, хотя до выходных все тоже прекрасно работало (сам файл dbf находится на удаленной машине).

запускаю такой запрос, где 749_050320_050418 - это имя ДБФ-ки
select * from OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'dBase 5.0;DATABASE=D:\dbf_folder', 'Select * from [749_050320_050418]')
и выдается сообщение об ошибке:

Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
[OLE/DB provider returned message: The Microsoft Jet database engine could not find the object '749_050320_050418'. Make sure the object exists and that you spell its name and the path name correctly.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IColumnsInfo::GetColumnsInfo returned 0x80004005: ].

Иногда , если переименовать имя ДБФ-ки в нормальное используя алфавитные символы, то запрос проходит, а иногда не проходит.

Пожайлуста проясните такое поведение сервера.

Anatoly Podgoretsky (2005-05-25 12:18:00) [40]
kivadim (25.05.05 10:40) [17]
По окончанию работы освобождает

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

Наверх

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