Удаление всех записей

← →
Patrick (2006-08-31 18:01) [0]

Хочу программно удалить все записи из таблицы Visual FoxPro.
фрагмент таков

a:TADOTable;

a.open;
a.deleterecords;
после чего выдается сообщение
Operation is not allowed in this context.

что это может означать?
заранее благодарен.

← →
ANB © (2006-08-31 19:02) [1]

> a.deleterecords;

Это означает, что так делать низзя.
Выполни запрос
"delete from имя_таблицы"
и не парся.
Правда, есть более шустрый способ (zap), но я сильно сомневаюсь, что из ADO он доступен.

← →
Anatoly Podgoretsky © (2006-08-31 19:07) [2]

ANB © (31.08.06 19:02) [1]
Доступен, если стоит правильный провайдер

← →
Palladin © (2006-08-31 19:44) [3]

> Правда, есть более шустрый способ

ага... drop table/create table :)

← →
Desdechado © (2006-08-31 20:15) [4]

truncate table
хотя, есть ли он в фоксе...

← →
ANB © (2006-09-01 09:11) [5]

> Desdechado © (31.08.06 20:15) [4]

в родном фоксе есть zap, а как его в локал SQL обозвали - х.з.

← →
Patrick (2006-09-01 09:18) [6]

В компоненте ADOTable метода ZAP нету,
а провайдер таков MSDASQL.1 наверное он верный.

← →
ANB © (2006-09-01 09:26) [7]

> В компоненте ADOTable

ADOTable тебе не поможет (возможно и есть метод, но искать долго). Используй SQL (ADOQuery).

← →
sniknik © (2006-09-01 11:35) [8]

> В компоненте ADOTable метода ZAP нету,
ZAP это sql команда вполне определенного движка VFP (у других не встречал, только у фокса)

> а провайдер таков MSDASQL.1 наверное он верный.
у этого провайдера (ODBC) у самого есь возможность подключится к любой базе. т.е. его приведение сдесь ни о чем не говорит.

> ADOTable тебе не поможет (возможно и есть метод, но искать долго). Используй SQL (ADOQuery).
нету и не может быть, в нем только методы доступа/взаимодействия к провайдеру/движку/sql серверу, работу выполняет всегда движок в ADO только посылается ответ от результата.
т.е. для того чтобы узнать что можно использовать, а что нет, надо читать хелп по используемому движку/sql серверу... если там можно, то и в ADO автоматически можно...

p.s. не используй ADOQuery! используй только родные ADO-шные компаненты - (ADOConnection,ADOCommand,ADODataSet) остальную муть для "затуманивания" мозгов с палитры ADO в корзину!

← →
Palladin © (2006-09-01 17:26) [9]

> не используй ADOQuery!

А почему? Есть серьезные минусы/недостатки?

← →
ANB © (2006-09-01 17:44) [10]

> Palladin © (01.09.06 17:26) [9]

sniknik на ADO собаку съел. Если советует, лучше так и делать.

← →
Palladin © (2006-09-01 17:58) [11]

да я тоже в общем то на ADOQuery собаку съел, это раз, два - если бы меня не интересовали причины я бы и не спрашивал, три - никому слепо не верю и тебе не советую, четыре - возможно названные минусы/недостатки будут абсолютно для меня не критичны.

← →
Anatoly Podgoretsky © (2006-09-01 19:02) [12]

Palladin © (01.09.06 17:26) [9]
Конечно, например не нужная трата ресурсов, используется TStrings, более частые ошибки у начинающих, что не видел такого кода?
Querty.Active := True; Query.Open;

← →
Palladin © (2006-09-01 19:07) [13]

:) ну скажем "код такого рода" мне по барабану, я для себя спрашивал...

> например не нужная трата ресурсов

а вот это уже гораздо более серьезный аргумент...

← →
Anatoly Podgoretsky © (2006-09-01 19:58) [14]

Различие перед AdoDataset в первую очередь в этом, я не понимаю, разве так написать тяжелее
AdoDataset.CommandText := "SELECT "+ " Fld1, "+ ... " FldN "+ "FROM Tbl ";
чем
AdoQuery.Cleae; AdoQuery.Add("SELECT "); AdoQuery.Add(" Fld1, "); ... AdoQuery.Add(" FldN "); ... AdoQuery.Add("FROM Tbl );

← →
Palladin © (2006-09-01 20:14) [15]

зато так написать, проще для меня

q.sql.text:=_MyFunctionToLoadSQLTemplateFromFile;
q.Open;
While Not q.Eof Do
Begin
...
q.Next;
End;
q.Close;

это единственные методы (не считая конечно: свойства Fields, фунции FieldByName и TADOBlobStream, очень редко используемый) которыми я пользуюсь при работе с TADOQuery

никогда не ложу TADOQuery на форму, бо не пользуюсь никакими DB контролами
изредка ложу ADOConnection, но в основоном использую TADOQuery.ConnectionString

в данном случае меня интересует есть ли значительное преимущество у _RecordSet перед TADOQuery.Fields

← →
SergP © (2006-09-01 20:20) [16]

> [14] Anatoly Podgoretsky © (01.09.06 19:58)
> Различие перед AdoDataset в первую очередь в этом, я не
> понимаю, разве так написать тяжелее
> AdoDataset.CommandText :=
> "SELECT "+
> " Fld1, "+
> ...
> " FldN "+
> "FROM Tbl ";
> чем
> AdoQuery.Cleae;
> AdoQuery.Add("SELECT ");
> AdoQuery.Add(" Fld1, ");
> ...
> AdoQuery.Add(" FldN ");
> ...
> AdoQuery.Add("FROM Tbl );

Хм... А причем тут сложность написания? Например я всегда так писал:
ADOQuery.SQL.text:="SELECT Fld1,FldN FROM Tbl";

Вот только привык к ADOQuery... Наверное нада будет отучаться, если это вредная привычка... :-)

← →
Palladin © (2006-09-01 20:22) [17]

и поймите, это не наезд :) и я прекрасно знаю что sniknik - знает нюансы ADO и того что с ним связано, в много раз больше чем я, потому и вопрошаю... для себя...

← →
Anatoly Podgoretsky © (2006-09-01 20:39) [18]

Palladin © (01.09.06 20:14) [15]
q.sql.text:=_MyFunctionToLoadSQLTemplateFromFile;
d.CommandText := _MyFunctionToLoadSQLTemplateFromFile;

в данном случае меня интересует есть ли значительное преимущество у _RecordSet перед TADOQuery.Fields
У TADOQuery нет Fields, его нет и у TAdoDataset, это свойства TDataset

TADOQuery это наследник от TAdoDataset с тремя дополнительными свойствами
DataSource
RowsAffected
SQL
и одним дополнительным методом ExecSql, что бы он мог быть многоголовой гидрой - и TAdoDataset и TAdoCommand

← →
Anatoly Podgoretsky © (2006-09-01 20:42) [19]

SergP © (01.09.06 20:20) [16]
Хм... А причем тут сложность написания? Например я всегда так писал:
ADOQuery.SQL.text:="SELECT Fld1,FldN FROM Tbl";

Я специально привел способ похожий на SQL.Add кроме того ты наверно заметил там ... вот оно может заменять гораздо более длинный текст.
Такой простой я конечно запиши или так
"SELECT Fld1,FldN FROM Tbl";
или так
"SELECT Fld1,FldN "+
"FROM Tbl";

Но при использовании SQL.text от ADOQuery практически ничего не остается.

← →
sniknik © (2006-09-01 20:44) [20]

> А почему? Есть серьезные минусы/недостатки?
основной минус это привычка для начинающих (это об ADOQuery а не ADOTable ;), там серьезнее), привыкать пользоваться заменителями когда есть оригиналы, мало хорошего, как минимум.
заменители эти были борландом сделаны для "облегчения" перехода с BDE (очень нужно конечно когда начинающий, и ни того ни другого не знаеш ;о)), причем сделано с попыткой подогнать логику к заменяемым компонентам, как это пролучилось яркий пример ADOTable, и как его используют (идеология разная а использовать пытаются одинаково), коряво в общем получилось, с ADOQuery не так очевидно но минусы есть.
как сделан ADOQuery? взят ADODataSet, на него навесили свойство SQL, вывели наружу внутренний ADOCommand, и обрезали все "лишнее".
на методе SQL практически сразу же словили глюк, изза того что адо принимает полный запрос в одной строке, а по логике (и привычке) в ADOQuery добавляют запрос по частям то получилась какаято байда с параметрами (вылет на частичном запросе, надо поискать, была частая ошибка, не помню точно. но счас это уже конечно исправили. просто показательно, что изза разных идеологий на такой мелочи и то глюк)
потом рушится четкое разделение мелкосовтских обьектов - выполнение в ADOCommand, обработка вернутого в рекордсете/ADODataSet, т.е. они это специально разьеденили, а борланд взял и обьеденил (в BDE было так и нефиг). отсюда и путаница ExecSQL/Open у начинающих.
ну и потом, когда надо чтобы код выполнялся быстро, на обновление базы например, а по привычке пользуются ADOQuery, т.е. подымают "монстра" нацеленного/разработаного для обработки рекордсета, ради встроенного в него обьекта всего лиш выполняюшего запрос... не проще/лучше ли непосредственно использовать этот отдельный обьект? (в смысле ADOCommand)
ну положим даже скорость не важна, пусть мы используем его близко по назначению как ADODataSet, но... ADODataSet один, а из него сделали 3 компонента ADOTable, ADOQuery, ADOStoredProc отличающиеся только (не считая исковерканной идеологии) предустановленными по разному свойствами... зашибись "облегчение", вместо одного компанента учить три (ну не то что там особо учить конечно... но зачем это тем кто BDE в глаза не видел?).

← →
Anatoly Podgoretsky © (2006-09-01 20:45) [21]

но в основоном использую TADOQuery.ConnectionString
Это плохо, не жалей бросить TADOConnection и не на форму, а в датамодуль.
Использование TADOQuery.ConnectionString приводит к торможам, ко множеству соединений к серверу, если будет более одного TADOQuery

← →
Anatoly Podgoretsky © (2006-09-01 20:51) [22]

были борландом сделаны для "облегчения" перехода с BDE
Я бы не сказал, что для "облегчения" перехода с BDE, больше для переноса старых проектов, а переход (новые проекты) должен уже делать без TADOQuery

← →
Anatoly Podgoretsky © (2006-09-01 20:52) [23]

Хотели как хорошо, а получилось как всегда.

← →
sniknik © (2006-09-01 20:55) [24]

> Использование TADOQuery.ConnectionString приводит к торможам, ко множеству соединений к серверу, если будет более одного TADOQuery
еще к неверным данным, изза кеширования, не помните вопросы в форуме "почему выполняю команду в одном квери, тут же обновляю другой отображающий, а данные не обновились?", были на форуме. а вот поэтому, что у компонент вместо конекта ConnectionString прописана... (тоже аналогия привычки с BDE, как прописывали путь в TQuery вместо использования Database та и идет...)

> Я бы не сказал, что для "облегчения" перехода с BDE
именно в такой формулировке только на английском и прочел в хелпе 6х/5х(?) дельфе (в 7ке уже нету), именно потому и решил, нафиг мне эти компоненты не нужны (с BDE вообще не работал, не потом пришлось... но с базами на дельфи начал именно с ADO), а вовсе не потому что изначально разглядел их "гнилую" сущьность ;о)). не было бы этой фразы... (а в семерке то нет ее (!!!))

Мне не повезло, много работал, а от TAdoQuery ты меня отвратил, не жалею :-)

> q.sql.text:=_MyFunctionToLoadSQLTemplateFromFile;
> d.CommandText := _MyFunctionToLoadSQLTemplateFromFile;

некритично

> У TADOQuery нет Fields, его нет и у TAdoDataset, это свойства
> TDataset

ок, но некритично

> TADOQuery это наследник от TAdoDataset с тремя дополнительными
> свойствами
> DataSource
> RowsAffected
> SQL
> и одним дополнительным методом ExecSql, что бы он мог быть
> многоголовой гидрой - и TAdoDataset и TAdoCommand

ну и хорошо, мне то что от этого? скорость доступа к набору данных от этого как то поменяется?

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

никогда не использовал BDE, и всегда использовал ADO, незначимо...

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

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

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

ну поднял я монстра, но один раз за все время работы и для многих целей, я могу сделать через него: как запрос с результирующим набором данных так и ExecSQL, разве не удобно?
или все таки (! вот это для меня важно знать)
ADOCommand.CommandText:="insert into t1 values (v1,v2)"; ADOCommand.Execute;будет выполнятся быстрее чем
ADOQuery.sql.text:="insert into t1 values (v1,v2)"; ADOQuery.ExecSQL;
(расходы на назначение TStrings.text не учитывать :) )

> ну положим даже скорость не важна,

она то, как раз, и важна для меня...

> зашибись "облегчение", вместо одного компанента учить три

Честно сознаюсь, из всего набора ADO компанентов использую лишь TADOQuery, редко TADOConnection, и учить их не собираюсь ибо работаю на уровне [15] Palladin © (01.09.06 20:14)

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

Вот это уже интересно, вот только если у меня есть больше чем 2-3 ADOQuery, то это значит, что работаю я с ними в разных потоках и смысла от ADOConnection при этом не вижу абсолютно...

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

мне по барабану построенная borland"ом архитектура, ее недостатки и нескладные, ломающие архитектуру ms, решения, я очень и очень ограниченно (моим 15 постом) использую ADOQuery, но общатся с данными удобно именно через него...

> или все таки (! вот это для меня важно знать)
> ADOCommand.CommandText:="insert into t1 values (v1,v2)";
> ADOCommand.Execute;будет выполнятся быстрее чем
> ADOQuery.sql.text:="insert into t1 values (v1,v2)";
> ADOQuery.ExecSQL;
> (расходы на назначение TStrings.text не учитывать :) )
вот в таком виде, и на одной команде разници не почуствуеш, в цикле на множественных инсертах можеш получить существенный выигрыш.
вообщето желательно на конкретном коде оптимизацию проводить не на "примерочном".
тут была как то ветка, комуто было критично время выполнения инсерта (чтото вроде пакет из 100 не более секуды должен был выполнятся), "ужали" время выполнения на порядок больше чем ему нужно было... первый шаг - отказ от ADOQuery в пользу ADOCommand, если не поменял бы то о дальнейших оптимизациях говорить не стоило бы.

> ADOCommand.CommandText:="insert into t1 values (v1,v2)";
тут еще нужно поменять непосредственные значения в запросе на параметры, сам запрос вынести за цикл, также определения параметров (ParamByName()) тудаже, в цикле только присвоение определенным уже параметрам значений и выполнение, + в опциях поставить, executenorecords, и можно (если не слишком быстрый запрос) asyncexecute. будет максимально быстро (расматриваем одиночные инсерты, не пакетные для внесений из файлов например).

> Вот это уже интересно, вот только если у меня есть больше чем 2-3 ADOQuery, то это значит, что работаю я с ними в разных потоках
нет, единственное, что это значит, что для каждого ADOQuery создастся свой коннект. и все. отдельных потоков никто не обещал.
вот например кинеш ты 33 ADOConnection-ов на форму, они будут работать в отдельных потоках?
(для того чтобы выполнение/подключения шли в паралельном потоке есть опции (asyncexecute), и не нужно других экзотических способов)
кстати куча потоков к одному серверу это же дополнительные тормоза. (на переключения/блокировки/взаимодействия между ними) в одной программе выгоднее один коннект (по обстоятельствам конечно, не всегда получается, но не просто же так кучу делать от незнания/упертости)

> и смысла от ADOConnection при этом не вижу абсолютно...
> ...
> но общатся с данными удобно именно через него...
ну тогда зачем спрашиваеш? хочеш чтобы тебя поуговаривали пользоваться тем чем нужно, и так как нужно? не видиш смысла? работай как видиш/хочеш. никто не заставляет.

> и все таки, есть ли различие в быстродействии между _RecordSet и ADOQuery.Fields для доступа к вернувшемуся набору данным?
не понятно упорство попыток "экономить на спичках", когда на привычках уже "дом заложил"...

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

ага, вот это очень и очень значимо, очень спасибо :) обязательно займусь рефакторингом если подтвердится экспериментально (конечно же при учете нижесказанного тобой)

> executenorecords, и можно (если не слишком быстрый запрос)
> asyncexecute

все опции ADOQuery, ставятся всегда на оптимизацию скорости возвращения результата, после TADOQuery.Create(Nil)...

в отдельной общепринятой процедуре выполняются

AutoCalcFields:=False; //эти Fields не использую CursorLocation:=clUseServer; CursorType:=ctOpenForwardOnly; EnableBCD:=False; //непомню почему, но в древности назначил :) LockType:=ltReadOnly; Prepared:=True;

> (для того чтобы выполнение/подключения шли в паралельном
> потоке есть опции (asyncexecute), и не нужно других экзотических
> способов)

ну ламер я в ADO, незнал (и не копал) о наиглавнейшем asyncexecute... очень полезно, спасибо, обязательно проведу экперименты...

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

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

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

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

ну... я уже сказал чуть повыше :)

> все опции ADOQuery, ставятся всегда на оптимизацию скорости возвращения результата, ....
> CursorLocation:=clUseServer;
> CursorType:=ctOpenForwardOnly;
проверь это + Last естественно (выкачать все данные рекордсета)
с CursorLocation:=clUseClient;
+ Last; (сделать аналогичное хотя и ненужное действие, клиентский выкачивает все сразу, чтобы не было преимущесв при проверке)

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

могу кстати выслать програмку на которой можно проверять твои запросы на скорость, не сказал бы что там все сильно оптимизировано... нет, просто по стандартам написано, можеш сравниват. ну правда одиночные запросы только...
хотя бы вот этот свой
CursorLocation:=clUseServer;
CursorType:=ctOpenForwardOnly;
Last;
на пару сотен тысяч записей
и там.

> но впечатление такое что перекачка "цельным куском" упаковывается
> чтоли

с Last в несильном далеке от Open замечал довольно часто (в режиме трассивоки ессно)... обьяснения кроме такого же как и у тебя не нашел :)

> (это у тебя от IB привычка? там однонаправленный курсор
> самый быстрый. говорил же, привычка страшная сила... ;)

да грю же ничего никогда не использовал кроме ADO, сразу после "подростового возраста после TP" плюнул на BDE и пр. схемы, что то внутре оттолкнуло от этого... :) более того к IB была устойчивая тошнота...

зато при изучении SQL Book Online от MS (MS SQL 7.0) однозначно повернуло в однонаправленный (forward_only), бо мне двунаправленный нафик не нужен если я получаю набор данных, который не будет обновлятся и вообще с ним чего то делаться, кроме как отображаться, не будет... как уже сказано ни один из DB контролов от borland я не использую и работаю по трехзвенке (специфика проектов далека от stable connections to DB)... и даже "упаковка" при last для меня чуть чуть играет роль лишь при небольшом локальном проекте...

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

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

> за окном шел снег и рота кавалерийстов

фу ты блин... оригинал: За окном шел снег и рота красноармейцев

Операция подсоединения к серверу дорогостоящая, и иметь независимый коннект в каждом Query (или в одном, но Close/Open) накладно, по сравнению с одним TAdoConnection постоянно подключеным. Только надо действительно иметь один на все приложение. Ну или пару, если особые условия.

> для совместимости конечно, не каждый день MS SQL...
там не важно, подойдет любой провайдер, изначально делалось под *.mdb.

послал.

упс... прошу прощения
ящик в анкете давно почил....

timu_r_r^v@ma_i^l.r^u

все знаки _ и ^ пропустить мимо ушей :)

Удаление всех записей Найти похожие ветки