Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Очистить всю таблицу DBF с помощью SQL [dBase, FoxPro]

Страницы: 1 2 >
Курдль © (2008-08-26 17:00:00)
Вот уж досталось мне наследие :(
Не думал, что придется вернуться в каменный век... FoxPro

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

Anatoly Podgoretsky (2008-08-29 15:45:00) [1]
> Курдль (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.

Курдль (2008-08-29 14:33:00) [2]

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

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

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

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

Сергей М. (2008-08-28 16:29:00) [3]
Удалено модератором

Раиса (2008-08-28 16:06:00) [4]
Виталий Панасенко © (28.08.08 15:47) [29]

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

Игорь Шевченко (2008-08-28 15:55:00) [5]

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

Автора!

Виталий Панасенко (2008-08-28 15:47:00) [6]

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

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

Раиса (2008-08-28 15:03:00) [7]
А я вообще тупо после delete from TABLE_NAME делаю select * from TABLE_NAME и с помощью BatchMove кидаю в таблицу с тем же именем. И вроде все работает и размер не увнличивается (как давно это было, и до сих пор работает в одной конторе).

Сергей М. (2008-08-28 08:29:00) [8]

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

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

Германн (2008-08-28 01:31:00) [9]

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

+1

Anatoly Podgoretsky (2008-08-27 23:24:00) [10]
> Курдль (27.08.2008 22:04:24) [24]

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

Курдль (2008-08-27 22:04:00) [11]

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

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

Polevi (2008-08-27 21:54:00) [12]
TRUNCATE TABLE ?

Сергей М. (2008-08-27 21:12:00) [13]

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

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

Виталий Панасенко(дом) (2008-08-27 19:26:00) [14]

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

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

Курдль (2008-08-27 16:43:00) [15]

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

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

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

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

Сергей М. (2008-08-27 16:29:00) [16]

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

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

Виталий Панасенко (2008-08-27 15:58:00) [17]
select канает, ZAP - нет

Виталий Панасенко (2008-08-27 15:55:00) [18]
Да и, кажись, можно тупо указать SourceDB=c:\, а затем "плясать" точно, так же, как и от алиаса БДЕ.. select * from 'c:\dbf\dbf.dbf' и т.д. в том числе и zap 'c:\dbf\dbf.dbf'

Виталий Панасенко (2008-08-27 15:52:00) [19]
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

Курдль (2008-08-27 15:46:00) [20]

> Виталий Панасенко © (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. Так там тоже без переподключения обнулить не удается.

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

Наверх

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