Вот уж досталось мне наследие :(
Не думал, что придется вернуться в каменный век... FoxPro

Кто поможет SQL-но очистить таблицу DBF?
А то DML
вызывает только пометку удаляемых записей, но не физическую их смерть.

С помощью SQL никак.
SQL не работает на уровне контейнера.

> Вот уж досталось мне наследие


В своей беде ты не одинок - многие несут такой же крест)

Что-то проклевывается.
Типа


Только между ними что-то надо предпринять типа закрытия коннекции или коммития транзакции (а то ругается, что DBF занят).

Нормально отработало.
Надо только между DML закрыть и открыть соединение (вот уж танцы с бубнами).

zap TABLE_NAME... если работать через VFP драйвер

"pack TABLE_NAME" и "zap TABLE_NAME" не являются SQL командами, они просто выдаются интерпритатору FoxPro для обработки.
Кстати, поскольку очистить надо всю таблицу, то второе правильно, без всякого "delete from TABLE_NAME".

Интерпритатору FoxPro можно передать любую команду, включая SQL, который также включен в Интерпритатор FoxPro. Надо просто понять, что в данном случае ведется прямая работа с интерпритатором, а не с SQL

Чем не понравилось Delete Table + Create Table ?

> Anatoly Podgoretsky ©   (27.08.08 00:49) [6]
> Надо просто понять, что в данном случае ведется прямая работа
> с интерпритатором, а не с SQL


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

А, кстати, DBF-овский SQL параметров не поддерживает? Мне не удалось добиться :(

> Виталий Панасенко(дом)   (26.08.08 20:11) [5]
> zap TABLE_NAME... если работать через VFP драйвер

zap TABLE_NAME через PleDb провайдер:

> Курдль   (27.08.08 12:52) [10]


Там, в VFPOLEDB? много еще чего не работает или работает не шибко прямо.
Если хочешь иметь полноценный корректный доступ к фоксовым премудростям, нужно пользовать полноценный VFP ран-тайм модуль. Его можно инсталлировать отдельно как самостоятельный продукт, т.е. целиком MSVFP ради этого устанавливать не нужно.

Дельфийская обертка к VFPRTL тоже существует, зовется foxauto

> Сергей М. ©   (27.08.08 14:22) [11]
> Если хочешь иметь полноценный корректный доступ к фоксовым
> премудростям, нужно пользовать полноценный VFP ран-тайм
> модуль.


Глаза б мои его не видели! :)
Имею ущербную приблуду на FoxPro, которую надо вкорячить... простите, ИНТЕГРИРОВАТЬ, в существующую автоматизированную систему. Имею MS VS 2005.
А "VFP ран-тайм модуль" чем юзается? COM-ом?
Я-то по рабоче-крестьянски из ADO.NET достукиваюсь...

> "VFP ран-тайм модуль" чем юзается? COM-ом?


Ага.
Это и есть СOM-сервер, только некоторым образом хитрозадый - просто так средствами тривиального вызова CreateComObject до него не достучаться, требуется довольно изощренная "прокладка", коей foxauto и является.

Автор foxauto, видимо, как раз заботился о горемыках типа тебя)

> Курдль   (27.08.08 12:52) [10]

А ODBC Visual FoxPro Driver нельзя юзать? Через OLE DB получилось только через анус: Delete from, отключить ADOConnection, подключить и pack.. без отключения/подключения получаю File in use

> Виталий Панасенко ©   (27.08.08 15:27) [14]
>
>
> > Курдль   (27.08.08 12:52) [10]
>
> А ODBC Visual FoxPro Driver нельзя юзать? Через OLE DB получилось
> только через анус: Delete from, отключить ADOConnection,
>  подключить и pack.. без отключения/подключения получаю
> File in use


Мне надо извлекать туеву хучу мелких базочек из разных папочек.
(Между прочим, это дорогостоящее промышленное решение, растиражированное не на одну крупную компанию!).
А ODBC сначала надо настраивать. Или нет? Программно я этого делать не умею.
Зато OLEDB подсовываешь путь к DBF-папке и все!

P.S. У меня Aqua Data Studio настроена на доступ к тестовым базам FoxPro через ODBC. Так там тоже без переподключения обнулить не удается.

DRIVER=Microsoft Visual FoxPro Driver (*.dbf);UID=;PWD=;SourceDB=z:\all;SourceType=DBF;Exclusive=No;BackgroundFetch=Ye s;Collate=Machine;Null=Yes;Deleted=Yes;
Обрати внимание на SourceDB
Это строка подключения ADOCOnnection

Да и, кажись, можно тупо указать SourceDB=c:\, а затем "плясать" точно, так же, как и от алиаса БДЕ.. select * from 'c:\dbf\dbf.dbf' и т.д. в том числе и zap 'c:\dbf\dbf.dbf'

select канает, ZAP - нет

> Виталий Панасенко ©   (27.08.08 15:58) [18]
>
> select канает, ZAP - нет
>


С какого перепугу zap обязан "канать" ?
FoxODBC-драйвер не обязан интерпретировать всякую фоксовую лабуду, не имеющую отношения к SQL92/99 и иже с ними

> Виталий Панасенко ©   (27.08.08 15:55) [17]
> Да и, кажись, можно тупо указать SourceDB=c:\, а затем "плясать"
> точно, так же, как и от алиаса БДЕ.. select * from 'c:\dbf\dbf.dbf'


Представляю, как бы выглядели мои связанные многотабличные запросы :)


> select канает, ZAP - нет

Так и чего мне тогда копья ломать? OLEDB все же роднее для ADO.NET.
Вот если бы параметрические запросы заработали...

> Сергей М. ©   (27.08.08 16:29) [19]

Просто "лобуда" типа PACK - канает

> Просто "лобуда" типа PACK - канает


А завтра, немаловероятно, автору потребуется, скажем, реиндексация.
А "просто "лобуда" типа REINDEX" при ODBC-решении не "проканает".
А автор уже сделал ставку на ODBC и настрогал уже кучу кода.

TRUNCATE TABLE ?

> Сергей М. ©   (27.08.08 16:29) [19]
> С какого перепугу zap обязан "канать" ?
> FoxODBC-драйвер не обязан интерпретировать всякую фоксовую
> лабуду, не имеющую отношения к SQL92/99 и иже с ними

Да! Но тогда нехило бы, шоб на SQL92/99 канало простое человеческое
! И при этом таблица свято очищалась бы от записей. Вот бы я возрадовался и на даже на форум бы не полез за запами и паками!

> Курдль  (27.08.2008 22:04:24)  [24]

У xBase есть уникальная возможность восстанавливать удаленые записи, кроме того ни обна мне известная база не делает упаковки после удаления. Просто некоторые повторно используют освобожденое место, но если надо уменьшить размер после удаления, то надо запускать процедуру упаковки. В некоторых СУБД это можно сделать с помощью SQL запроса, в других надо запускать отдельную утилиту.

> Сергей М. ©   (26.08.08 17:10) [2]
>
>
> > Вот уж досталось мне наследие
>
>
> В своей беде ты не одинок - многие несут такой же крест)
>

+1

> Курдль   (27.08.08 22:04) [24]


Я ж тебе предложил решение в [11],[13] - там канает абсолютно все касаемое фокса и при этом тф остаешься в привычной дельфийской среде с ее дейтасетами

А я вообще тупо после delete from TABLE_NAME делаю select * from TABLE_NAME  и с помощью BatchMove кидаю в таблицу с тем же именем. И вроде все работает и размер не увнличивается (как давно это было, и до сих пор работает в одной конторе).

> Раиса ©   (28.08.08 15:03) [28]
> А я вообще тупо после delete from TABLE_NAME делаю select
> * from TABLE_NAME  

И, цикаво, что ж тогда у нас там выбирается? Данные то уже удалены

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


Автора!

Виталий Панасенко ©   (28.08.08 15:47) [29]

Выбирается всё, что там осталось после удаления по условию Where, например. Я подумала, что и автор вопроса удаляет не все записи, а по условию.

Удалено модератором

> Anatoly Podgoretsky ©   (27.08.08 23:24) [25]
> У xBase есть уникальная возможность восстанавливать удаленые
> записи, кроме того ни обна мне известная база не делает
> упаковки после удаления. Просто некоторые повторно используют
> освобожденое место, но если надо уменьшить размер после
> удаления, то надо запускать процедуру упаковки. В некоторых
> СУБД это можно сделать с помощью SQL запроса, в других надо
> запускать отдельную утилиту.


Спасибо! Я не лезу своим свиным рылом в калашный ряд DBA. Меня не интересуют проблемы упаковки БД. Мне важно, чтобы мои программы работали исправно в оговоренных ТЗ условиях аппаратного и спец. программного обеспечения. Еще мне важно, чтобы СУБД, позволяющие использовать SQL и DML над своими данными, придерживались хотя бы базовых стандартов.


> Сергей М. ©   (28.08.08 08:29) [27]
> Я ж тебе предложил решение в [11],[13] - там канает абсолютно
> все касаемое фокса и при этом тф остаешься в привычной дельфийской
> среде с ее дейтасетами

Спасибо! Я не могу себе позволить нагромождать проект специфическими драйверами, протоколами компонентами и т.п.

> Курдль  (29.08.2008 14:33:33)  [33]

Какой еще DBA для xBase - это всегда было заботой конечного пользователя. Для этого Борланд предоставляет BDE Admin для поставки конечному пользователю.
Кроме того программист может поместиь в меню обслуживания программы два пункта -

1. Очистка таблицы (EmptyTable - работает мгновенно)
2. Сжатие таблицы (dbiPackTable)

Или может вызывать второй пункт автоматически при определенных условий. Но это относится к первой части твоего вопроса
> Очистить всю таблицу DBF с помощью SQL [dBase, FoxPro]
Для VFPOLEDB это конечно не подходит. Но тебе одно из решений тебе привели (foxauto), второе ("pack TABLE_NAME" и "zap TABLE_NAME" ), но эти два надо уметь применять, просто так их в запросе приводить нельзя, надо вызывать, что то подобное exec FOXPRO сомманд, точно я не помню, поскольку FoxPro не использую, но именно это приводили в форумах как решение, и не кто не гарантирует, что это будет работать для всех команд FoxPro

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

И о каких базовых стандартах SQL и DML, в части упаковки или очистки таблиц, ты говоришь, такие операции стандартом не предусмотрены и реализуются в разных СУБД по разному, от запросов MS SQL до утилит БДЕ или функций dbiPackTable/EmptyTable.