Быстрый вывод в текстовый файл?

← →
Razrab © (2007-12-10 11:53) [0]

Добрый день, коллеги!
Подскажите способ быстрого, непострочного вывода информации в текстовый файл, если таковой вообще возможен в Delphi. Столкнулся со следующей проблемой: вывожу при помощи стандартного построчного вывода в цикле через Writeln() данные из Oracle в текстовый файл. И все бы ничего, но в одном текстовом файле количество строк 300 с лишним тысяч. В результате, создание такого файла у пользователя занимает 1 час с копейками, многовато. Каким образом можно было бы создать текстовый файл не построчно, а одним махом туда запихнуть данные из Select-а?
Заранее благодарю за помощь.

← →
Сергей М. © (2007-12-10 11:58) [1]

А можно полюбопытствовать, зачем клиенту понадобился такой файл ?

← →
Razrab © (2007-12-10 12:05) [2]

Это sql-файл набора Insert-ov из таблицы - всего более 300.000 Insert-ov. У клиента нет доступа к нашей БД, и он грузит к себе данные просто запуская набор подобных sql-файлов, которые получает по e-mail.

← →
Сергей М. © (2007-12-10 12:13) [3]

Показывай в коде, как формируешь файл ..

← →
clickmaker © (2007-12-10 12:30) [4]

> [2] Razrab © (10.12.07 12:05)
> Это sql-файл набора Insert-ov из таблицы - всего более 300.000
> Insert-ov

а импорта-экспорта в Оракле нету? Типа bcp в MS SQL

← →
DrPass © (2007-12-10 12:44) [5]

> Это sql-файл набора Insert-ov из таблицы - всего более 300.
> 000 Insert-ov.

А не слишком ли нездоровый способ? Может, стоит выполнить bulk load? Наверняка ж он и в Оракле есть.
Тем более что 1 час на выгрузку 300000 строк - это скорее в основном не из-за сохранения в файл, а из-за выгрузки данных из БД.

← →
DrPass © (2007-12-10 12:51) [6]

Кстати, даже проверил - секунд 20, и при этом еще и с ProcessMessages

procedure TForm1.Button1Click(Sender: TObject); var f: Textfile; i: integer; begin AssignFile(f, "c:\txt.txt"); Rewrite(f); for i := 1 to 300000 do begin writeln(f, "Съешь ещё этих мягких французских булочек да выпей чаю!"); Button1.Caption:= IntToStr(i); end; CloseFile(f); end;

← →
palva © (2007-12-10 12:52) [7]

Если выводить файл блоками, скажем по 10 кб, то это будет существенно быстрее, чем строками по 80 байт. Сделать это несложно, и вам здесь подскажут, как. Советую, однако, сначала выяснить причину тормозов.

← →
DiamondShark © (2007-12-10 12:57) [8]

Тормоза точно не из-за метода доступа к файлу.
Скорее, из-за метода построения строки для записи в файл.

Но это гадание на кофейной гуще. Показывай код.

← →
Razrab © (2007-12-10 14:49) [9]

Вот процедура по которой формируется текстовый файл:

procedure outfiles(var F: TextFile; ADOqr: TADOQuery);
var i: integer;
begin
ADOqr.Active := True;
ADOqr.First;
for i := 0 to ADOqr.RecordCount - 1 do
begin
WriteLn(F, ADOqr.FieldByName("LINE").AsString);
ADOqr.Next;
end;
ADOqr.Active := False;
end;

Коннект через ADO. Похоже что тормоза возникают не из-за построчной записи, а из-за построчной проходки запроса. Но как в данном случае еще можно реализовать, ума не приложу?

← →
palva © (2007-12-10 14:57) [10]

> Но как в данном случае еще можно реализовать, ума не приложу?
В ADO есть метод Save позволяющий сохранить весь рекордсет в виде XML-файла. Не знаю, будет ли это быстрее. Да еще и обработка этого файла понадобится.

← →
Razrab © (2007-12-10 15:02) [11]

А что если данные из базы сначала в массив загонять, а уже после из него построчно писать в файл? Есть еще варианты?

← →
Сергей М. © (2007-12-10 15:03) [12]

> Razrab © (10.12.07 14:49) [9]

> ADOqr.RecordCount

Здесь засада №1

> FieldByName

Здесь №2

← →
Palladin © (2007-12-10 15:07) [13]

ADOqr.Active := True;
ADOqr.First; // на кой? думаешь курсор после открытия на последней стоит?
for i := 0 to ADOqr.RecordCount - 1 do // зачем? однопроходный ведь
begin
WriteLn(F, ADOqr.FieldByName("LINE").AsString); // лучше по индексу
ADOqr.Next;
end;
ADOqr.Active := False;

пробуй это

ADOqr.CursorLocation:=clUseServer;
ADOqr.CursorType:=ctOpenForwardOnly;
ADOqr.LockType:=ltReadOnly;
ADOqr.Open;
While Not ADOqr.Eof Do
Begin
WriteLn(f,ADOqr.Fields[индекс].AsString);
ADOqr.Next;
End;
ADOqr.Close;

← →
Palladin © (2007-12-10 15:09) [14]

надеюсь никакой контрол у тебя к нему не привязан :)

← →
Razrab © (2007-12-10 15:11) [15]

Сергей М.

А что цикл while not ADOQuery.Eof do и обращение к полю по индексу будут быстрее?! %) Или я не так понял Ваш намек?

← →
Palladin © (2007-12-10 15:13) [16]

> Razrab © (10.12.07 15:11) [15]

> обращение к полю по индексу будут быстрее?

ну так надо думать то головой... то ли объекту искать поле по имени в цикле по всем полям сравнением, да еще и с Case-Insentivity, то ли обращатся на прямую к полю в массиве

← →
{RASkov} © (2007-12-10 15:15) [17]

> [15] Razrab © (10.12.07 15:11)

Лучше ответь на [14])
Может у тебя грид скролится во время вывода....

← →
Razrab © (2007-12-10 15:18) [18]

Palladin

> надеюсь никакой контрол у тебя к нему не привязан :)

Ну как? Сам коннект работает через ADOConnection и ADOQuery, размещенные на форме. Поскольку запросы весьма громоздкие, то в ADOQuery Select-ы занесены в свойство SQL, чтобы кучу всяких кавычек не ставить.

← →
Сергей М. © (2007-12-10 15:19) [19]

> Razrab © (10.12.07 15:11) [15]

По поводу RecordCount - свойство возвращает гарантированно правильный результат только в том случае, если предварительно был выполнен метод Last.

По поводу обращения к объекту-полю по индексу - да, и ощутимо.

← →
Palladin © (2007-12-10 15:20) [20]

> Razrab © (10.12.07 15:18) [18]

имеется ввиду XXXDBGrid семейство

← →
Palladin © (2007-12-10 15:22) [21]

> Сергей М. © (10.12.07 15:19) [19]

отнюдь не всегда... во первых провайдер должен поддерживать его, во вторых зависит от кучи (ну на самом деле не такой уж и большой кучи) настроек соединения и объекта RecordSet, например в указанных в моем примере настройках RecordSet"а RecordCount не вернется... по крайней мере это справедливо для Jet и MSSQL

← →
Palladin © (2007-12-10 15:24) [22]

да и вообще, если честно, на него вообще полагаться не стОит :) и пользоваться тоже... если конечно не затачивать программу под конкретный провайдер

← →
Razrab © (2007-12-10 15:25) [23]

Palladin

А почему while то быстрее чем for?

← →
DiamondShark © (2007-12-10 15:26) [24]

> Razrab © (10.12.07 15:25) [23]
> Palladin
>
> А почему while то быстрее чем for?

Он не быстрее, он правильнее.
Как тебе уже сказали, RecordCount после открытия не обязан возвращать точное количество записей.

← →
{RASkov} © (2007-12-10 15:27) [25]

> [23] Razrab © (10.12.07 15:25)

Не быстрнее....
Только если ты не заметил, то разговор не об этом....)

← →
Razrab © (2007-12-10 15:27) [26]

Palladin

DBGrid-ов у меня нет.

← →
sniknik © (2007-12-10 15:27) [27]

> надеюсь никакой контрол у тебя к нему не привязан :)
неважно, посмотри реализацию компонент, при явном отключении проверка на одном, верхнем уровне, при отсутствии контрола "на пару этажей ниже".
и раз уж идет борьба за скорость...

в общем советую в любом случае отключать. как и сменить ADOQuery на ADODataSet... советую, советую... а толку нет.

← →
{RASkov} © (2007-12-10 15:29) [28]

> [26] Razrab © (10.12.07 15:27)

Усё равно DisableControls не помешает)

← →
Razrab © (2007-12-10 15:46) [29]

И еще, не пойму как иногда вообще без RecordCount обходиться?! %) Ведь скажем, при выводе в тот же Excel, у которого ограничение на 65000 строк на лист, куда быстрее после Open узнать кол-во записей сразу по RecordCount, нежели перед одним полным Select-ом еще и Select Count(*) выдавать. Смысл?

← →
DrPass © (2007-12-10 15:53) [30]

> Сергей М. © (10.12.07 15:19) [19]
>
> > Razrab © (10.12.07 15:11) [15]
>
>
> По поводу RecordCount - свойство возвращает гарантированно
> правильный результат только в том случае, если предварительно
> был выполнен метод Last.

У ADODataset оно, в отличие от других датасетов, все-таки показывает именно количество записей в наборе, а не количество выфетченных записей. Насколько я знаю, потому что ADODataset в двунаправленном режиме не поддерживает страничный фетч, а сразу тупо фетчит на себя весь датасет.

← →
DrPass © (2007-12-10 15:55) [31]

> Ведь скажем, при выводе в тот же Excel, у которого ограничение
> на 65000 строк на лист, куда быстрее после Open узнать кол-
> во записей сразу по RecordCount

Не вижу связи первого со вторым

← →
Palladin © (2007-12-10 15:58) [32]

> Razrab © (10.12.07 15:46) [29]

Ты не представляешь на сколько редки подобные ситуции и в связи с их редкостью абсолютно не в падлу сделать count(*)

← →
Сергей М. © (2007-12-10 16:04) [33]

> DrPass © (10.12.07 15:53) [30]

Сегодня ADODataset, завтра еще какой-нить XXXDataset - рано или поздно грабли выстрелят. Именно на этом я и заострил внимание во фразе "засада №1".
Ни более ни менее. Работает оно сейчас у Автора - да ну и слава богу)

← →
Palladin © (2007-12-10 16:08) [34]

> sniknik © (10.12.07 15:27) [27]

когда то замерял

ADOQuery и ADODataSet на MSSQL и Jet, абсолютно равны по производительности, при ltReadOnly,clUseServer и ctOpenForwardOnly

:) более того на Jet если делать просто тупой цикл
While Not q.Eof Do q.Next;
ADOQuery в два раза быстрее :) ну это понятно ерунда хоть и прикольно... :)

← →
DrPass © (2007-12-10 16:51) [35]

> ADOQuery и ADODataSet на MSSQL и Jet, абсолютно равны по
> производительности

Логично, т.к. первый класс от второго отличается только тем, что CommandText выведен в свойство SQL, в остальном они тождественны

← →
Razrab © (2007-12-10 16:57) [36]

Спасибо, коллеги, ВСЕМ кто пытался помочь и реально помог, сейчас все заработало практически со скоростью самих запросов! :) А лекарство вот, напоминаю вышеприведеннный уважаемым Palladin-ом код:

ADOqr.CursorLocation:=clUseServer;
ADOqr.CursorType:=ctOpenForwardOnly;
ADOqr.LockType:=ltReadOnly;
ADOqr.Open;
While Not ADOqr.Eof Do
Begin
WriteLn(f,ADOqr.Fields[индекс].AsString);
ADOqr.Next;
End;
ADOqr.Close;

Так что, если еще кто на подобные грабли наступит ответ готов и выделен жирным. ;)

← →
slavakaram (2007-12-10 17:13) [37]

Есть бесплатный компонент kbMemTable - Потомок Dataset. Можно воспользоваться им. Единственно, что он возможно выводит все в CSV-формате, потому максимум 65536 строк. Но зато быстро

← →
Razrab © (2007-12-10 17:17) [38]

Palladin

> Ты не представляешь на сколько редки подобные ситуции и
> в связи с их редкостью абсолютно не в падлу сделать count(*)

У нас как раз бывает частенько. :) Юзер хочет видеть данные из БД в Excel, при это заранее даже не задумываясь об их количестве и естественно ограничении самого Excel. Выполнение трехэтажного Select для вывода таких данных порой может доходить до 30-40 минут. Если еще запустить count(*) на такой же промежуток времени, они очумеют. :) Поэтому предпочитаю RecordCount, благо дело под Oracle он вроде без проблем работает.

В Oracle top нет. Там можно правда через Rownum вложенно выводить от сих до сих. Но я когда увидел, что RecordCount работает, сделал через него. Правда выше уже коллеги напугали, мол до поры до времени. %) Ну на всякий случай буду иметь в виду. :)

> ADODataset в двунаправленном режиме не поддерживает страничный фетч, а сразу тупо фетчит на себя весь датасет.
поддерживает, нужно просто установить асинхронную докачку данных в настройках.
(это у других наоборот нет "тупого" фетча всего себя. хотя этот вариант в некоторых случаях быстрее. (по общей сумме времени работы, т.е. в случаях если сразу известно что рекордсет нужен на клиенте весь))

> ADOQuery в два раза быстрее :) ну это понятно ерунда хоть и прикольно... :)
это тем более прикольно, тем, что такого попросту не может быть...

берем мотоцикл, вешаем ему сбоку люльку без колеса, так чтобы она только ездить мешала, потом устраиваем гонку с оригиналом и выясняем, что этот уродец стал в 2 раза быстрее ездить.... ты в это поверишь? я нет. ты гдето ошибся в тестах.

и вообще производительность тут не причем, сменить следует по идеологическим мотивам. (ADOQuery это призрак BDE)

> sniknik © (10.12.07 17:59) [41]

вот именно, идеологические мотивы :) ну да ладно, темы религии касаться не будем...

а вот про быстрее в два раза - принципиально повторил эксперимент

таблица 36 полей int, 8 полей real, 500 000 записей

var d:TADODataSet; q:TADOQuery; tc:Cardinal; i,j:Integer; s:String; begin d:=TADODataSet.Create(Nil); d.Connection:=ADOConnection1; d.CommandText:="select * from tbl1"; d.CommandType:=cmdText; d.LockType:=ltReadOnly; d.CursorLocation:=clUseServer; d.CursorType:=ctOpenForwardOnly; For i:=0 to 2 Do Begin tc:=GetTickCount; d.Open; While Not d.Eof Do d.Next; d.Close; Memo1.Lines.Add("TADODataSet:Pass("+IntToStr(i)+"):"+IntToStr(GetTickCount-tc)); Application.ProcessMessages; End; d.Free; q:=TADOQuery.Create(Nil); q.Connection:=ADOConnection1; q.LockType:=ltReadOnly; q.CursorLocation:=clUseServer; q.CursorType:=ctOpenForwardOnly; q.sql.Text:="select * from tbl1"; For i:=0 to 2 Do Begin tc:=GetTickCount; q.Open; While Not q.Eof Do q.Next; q.Close; Memo1.Lines.Add("TADOQuery:Pass("+IntToStr(i)+"):"+IntToStr(GetTickCount-tc)); Application.ProcessMessages; End; q.Free; end;

единственное что конечно, MSSQL удленный, а db1 ( :) ) сдесь же на машине
а так... подтвердились результаты позапрошлогоднего опыта...
мож я с DataSet не умею работать... :)

> а так... подтвердились результаты позапрошлогоднего опыта...
?
чегото у меня никаких чудес с двукратным превосходством в скорости
~500 тыс записей, результат работы программы
TADODataSet:Pass(0):3062
TADODataSet:Pass(1):3079
TADODataSet:Pass(2):3062
TADOQuery:Pass(0):3063
TADOQuery:Pass(1):3046
TADOQuery:Pass(2):3063

в 2 раза "утяжелил" таблицу (время > в 2 раза, выдать уже своп затрагивается...)
TADODataSet:Pass(0):7438
TADODataSet:Pass(1):7546
TADODataSet:Pass(2):7579
TADOQuery:Pass(0):7562
TADOQuery:Pass(1):7578
TADOQuery:Pass(2):7547

что называется "ноздря в ноздрю", практически одинаково, как в принципе и ожидалось учитывая, что тестируется практически один и тот же компонент.

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

хм... WinXP, MS Office 2000, 1Gb Mem... ровно (почти) в два раза, но ADOQuery... даже не знаю... MSSQL 2000 на W3k, Xeon 3.2 с 4Gb ... локальный целерон 2.8...

в общем вот тестируемая таблица

CREATE TABLE [dbo].[tbl1] (
[ID_DATA] [int] NOT NULL ,
[ID_SERVICE] [tinyint] NOT NULL ,
[DEBT_BEFORE] [int] NOT NULL ,
[BNF_BNF] [int] NOT NULL ,
[BNF_BNF1] [int] NULL ,
[BNF_W_BNF] [int] NOT NULL ,
[SUB_BNF] [int] NOT NULL ,
[SUB_W_BNF] [int] NOT NULL ,
[SUB_ALL] [int] NOT NULL ,
[COR_W_BNF] [int] NOT NULL ,
[FINE] [int] NOT NULL ,
[REC_BNF] [int] NOT NULL ,
[REC_W_BNF] [int] NOT NULL ,
[REC_SUB_ALL] [int] NOT NULL ,
[REC_FINE] [int] NOT NULL ,
[FINE_ENABLED] [tinyint] NULL ,
[CALC_MODE] [tinyint] NOT NULL ,
[FORMULA_FILE] [int] NULL ,
[ADDITION] [real] NOT NULL ,
[COEFF] [real] NOT NULL ,
[GROUP_VAL] [real] NOT NULL ,
[ID_GCOUNTER] [int] NULL ,
[TARIFF_VAL] [real] NOT NULL ,
[TARIFF_ID] [int] NULL ,
[SHORT_DELIV] [tinyint] NOT NULL ,
[FLAG] [int] NULL ,
[SUPPLIER_ID] [int] NULL ,
[NORM_VAL] [real] NOT NULL ,
[NORM_ID] [int] NULL ,
[ID_GROUPBYSUP] [int] NULL ,
[FINE_DEBT] [int] NOT NULL ,
[FINE_CORR] [int] NOT NULL ,
[PEOPLE_COUNT] [real] NULL ,
[SUM_PAY] [int] NULL ,
[SUM_PAY_FINE] [int] NULL ,
[COUNTER_VOL] [real] NULL ,
[NON_DELIV] [int] NULL ,
[SUB_ALL1] [int] NULL ,
[SUB_ALL2] [int] NULL ,
[INFO1] [varchar] (255) COLLATE Cyrillic_General_CI_AS NULL ,
[NO_DEBT_RECALC] [int] NULL
)

заполнена она, конечно, реальными данными, в Jet перенесено стандартным Import/Export Wizard из MSSQL без всяких модификаций 1 000 000 записей... столько выбирать при тесте я не дождался и сократил до top 50 000...

подозрение на увеличение производительности ADODataSet падает, только на отсутствие varchar

> в общем вот тестируемая таблица
без ключа? ужас. хотя на тест влияния это не должно оказывать

вот, изменил тест так чтобы коннект и запрос можно было менять (проврить на реальных данных)
var tc: Cardinal; i : integer; begin with ADOConnection1 do begin Close; ConnectionString:= EdConnectionString.Text; Open; end; with TADODataSet.Create(nil) do try Connection := ADOConnection1; LockType := ltReadOnly; CursorLocation:= clUseServer; CursorType := ctOpenForwardOnly; CommandText := EdCommandText.Text; for i:=0 to 2 do begin tc:= GetTickCount; Open; while not Eof do Next; Close; Memo1.Lines.Add("TADODataSet: Pass ("+IntToStr(i)+") : "+IntToStr(GetTickCount-tc)); Application.ProcessMessages; end; finally Free; end; with ADOConnection1 do begin Close; ConnectionString:= EdConnectionString.Text; Open; end; with TADOQuery.Create(nil) do try Connection := ADOConnection1; LockType := ltReadOnly; CursorLocation:= clUseServer; CursorType := ctOpenForwardOnly; sql.Text := EdCommandText.Text; for i:= 0 to 2 do begin tc:= GetTickCount; Open; while not Eof do Next; Close; Memo1.Lines.Add("TADOQuery: Pass ("+IntToStr(i)+") : "+IntToStr(GetTickCount-tc)); Application.ProcessMessages; end; finally Free; end; end;

сдесь весь "проект", на всякий случай с екзешником... а вдруг у тебя генофонд злодеи изменили... проверишь на моей компиляции
http://www.filefactory.com/file/ec0975/

файл я делал так (твоих реальных данных у меня нет)
CREATE TABLE tbl1 ( ID INT Identity(1, 1) PRIMARY KEY, Name VarChar(50), Descr VarChar(50), Fl1 Float DEFAULT RAND(), Fl2 Float DEFAULT RAND(), ... Fl32 Float DEFAULT RAND() )

после внес одну запись руками с Name="Test" Descr="Test"
и много раз подряд
INSERT INTO tbl1 (Name,Descr) SELECT Name,Descr FROM tbl1
пока в итоге не получилось 524288 записей. на ней и тестил, кто хочет может повторить

результат последнего теста... ;)
TADODataSet: Pass (0) : 3125
TADODataSet: Pass (1) : 3125
TADODataSet: Pass (2) : 3125
TADOQuery: Pass (0) : 3125
TADOQuery: Pass (1) : 3125
TADOQuery: Pass (2) : 3125

Объясните такую вещь, зачем Вы создаете визуальные компоненты через конструктор: TADOQuery.Create(nil) ?
Это разве не одно и тоже, что взять и ADOQuery на DataModule или на форму кинуть, только менее удобно. В чем выигрыш и есть ли он в данном случае вообще?

А где создание визуального компонента?

> зачем Вы создаете визуальные компоненты через конструктор: TADOQuery.Create(nil) ?
ну во первых не визуального... во вторых это видиш ли был пример, притом приведенный в форуме (изначально) где настроек положенного на датамодуль компонента не видно, а у созданного так-"как на ладони", и видно что никто ничего не забыл/не делает нестандартно, что меняются только то что показано остальное гарантированно по дефаулту.
можно было бы вместо этого листинг dfm привести, и потом сравнивать в 2 х местах... но это уже как то слишком вместо десятка строк самоочевидного кода.

> В чем выигрыш и есть ли он в данном случае вообще?
т.е. с учетом вышесказанного, в данном случае выигрыш очевиден, не находишь? а вообще нету его.

> ну во первых не визуального

Я имел в виду VCL. Определение: библиоте́ка визуа́льных компоне́нтов (англ. Visual Component Library, VCL) — объектно-ориентированная библиотека для разработки программного обеспечения, разработанная компанией «Borland» по принципам визуального программирования. VCL компонент - это не обязательно видимый на форме пользователя, чем ADOQuery то не подходит? Ну да ладно, вопрос то был не в этом и вы на него выше ответили. :)

> Я имел в виду VCL.
а написал то совсем другое...

> VCL компонент - это не обязательно видимый на форме пользователя
понимаешь же... а вот "визуальный компонент" это именно видимый.

> чем ADOQuery то не подходит?
да ничем. кроме того что пудрит мозги начинающим.
вот скажи, ты когда суп кушаешь имеешь при себе 2 ложки? ну типа, чтобы одной из тарелки зачерпывать, потом из нее в другую переливать и уже эту ко рту подносить. (??? )
а ведь это единственная(!) функция прикрученного свойства SQL, ты команду в него, он в CommandText и вся его работа. ну, вот, нафига? хотя бы чисто с эстетической точки зрения.
(тонкие идеологические различия не убеждают "упертых". я проверял. они их просто не понимают, не хотят, аргумент один "но ведь работает же. так почему же он не подходит?", а другой тоже работает, но к нему тот же аргумент у них почемуто "не катит"...)

> sniknik © (13.12.07 00:56) [52]

О! Теперь и я знаю почему совет использовать TADOQuery есть BadTips.
А заглянув в ADODB.pas понял и про TADOTable.

P.S. Раньше как-то недосуг было заняться этими вопросами.
Правда и сейчас недосуг, но раз уж в форуме увидел что-то, то...
:)

> sniknik © (13.12.07 00:56) [52]

под "упертыми" я подразумеваюсь? :) я не упертый, мне им удобней пользоваться... в основном большинстве случаев я им пользуюсь только для чтения, в другом меньшинстве случаев для вставки или обновления... разницы в быстродействии - нет... религиозные убеждения меня не убеждают... никогда не писал и не собираюсь писать приложения на основе DB контролов... ну а если не видно разницы, то зачем делать больше телодвижений при кодировании?

> sniknik ©

если, конечно, это хоть немножко смягчит твой правденый гнев, то могу сказать, что при разработке ASP приложений я пользуюсь Native объектами ADO и ADOX :)

Быстрый вывод в текстовый файл? Найти похожие ветки