DELETEALL в SQL

[ОльгаМ]

Добрый день!

Поскольку Temp-файл ограничен в объеме 2 гб, мне приходится его периодически чистить.
Для этого я пользовалась DELETEALL.
К сожалению, когда он большой, то чистка его занимает также приличное время.
Сделала его постоянным и написала функцию удаления на SQL.
Увы, я уже второй раз сталкиваюсь с этой проблемой, по какой-то причине SQL второй раз не хочет его чистить.
Привожу фрагменты:

ConnectSQL();
_TableName := STRSUBSTNO('[dbo].[%1', COMPANYNAME) + '$Debts Forma 5 Buffer]';
_TableName1 := STRSUBSTNO('[dbo].[%1', COMPANYNAME) + '$Debts Forma 5 Buffer1]';
strSQL := STRSUBSTNO('USE [%1]; SET LOCK_TIMEOUT -1;',DatabaseName);
strSQL += 'declare @str varchar(4000)';
strSQL += ' set @str = ''DELETE with(TABLOCK) FROM ''+' +'''' + _TableName+ ''''+ '' +
'+'' DELETE with(TABLOCK) FROM ''+' +'''' + _TableName1+ ''''+ ''+ ' exec (@str)';

..................
adocon.Execute(_strSQL);

[Constantine_imported]

helga7289, а если получившийся запрос из SSMS выполнить, он нормально отрабатывает? Т.е. нужно локализировать проблему, она в НАВе или в SQL'е?
И что значит не хочет чистить второй раз? Второй раз вообще или второй раз подряд, какие-то ошибки дает или просто данные из таблиц не удаляет?

[ОльгаМ]

Проблема в Навике. Отрабатывает без каких либо сообщений. Message о COUNTе до и после не меняется, данные не удаляются.
Первый раз удаляет.

[Constantine_imported]

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

[rmv]

Файл (таблица?) в 2 гига это конечно круто, я вот ни разу не сталкивался с такими размерами буферных таблиц. Видимо не с теми я базами работаю.
По сабжу - варианты в порядке приоритетов которые я бы использовал:
1. Пересмотрел код в Наве на предмет зачем мне буфер в 2 Гига.
2. Если все не же никак - перенес формирование буфера и заливку в результирующие таблицы на SQL
3. Если и п.2 невыполним - плюнул бы на безопасность и написал truncate table

[ОльгаМ]

Цитата:

Сообщение от rmv

Файл (таблица?) в 2 гига это конечно круто, я вот ни разу не сталкивался с такими размерами буферных таблиц. Видимо не с теми я базами работаю.
По сабжу - варианты в порядке приоритетов которые я бы использовал:
1. Пересмотрел код в Наве на предмет зачем мне буфер в 2 Гига.
2. Если все не же никак - перенес формирование буфера и заливку в результирующие таблицы на SQL
3. Если и п.2 невыполним - плюнул бы на безопасность и написал truncate table

2.Алгоритм формирования буферной таблицы слишком сложный, и в конечном счете, эти данные распределяются по ячейкам Excel таблицы (Отчет по видам задолженности ДЗ и КЗ по огромной 17-ой таблице.)
3.truncate table работает аналогично DELETE FROM, т.е. второй раз не чистится.

[rmv]

Цитата:

Сообщение от helga7289

2.Алгоритм формирования буферной таблицы слишком сложный, и в конечном счете, эти данные распределяются по ячейкам Excel таблицы (Отчет по видам задолженности ДЗ и КЗ по огромной 17-ой таблице.)

Жесть конечно. 2 Гига это примерно пара мульонов контрагентов (или документов не знаю что у вас там в отчете). В Эксель все влазит? Если с утра запустили к обеду успевает построиться?

[ОльгаМ]

Цитата:

Сообщение от rmv

Цитата:

Сообщение от helga7289

2.Алгоритм формирования буферной таблицы слишком сложный, и в конечном счете, эти данные распределяются по ячейкам Excel таблицы (Отчет по видам задолженности ДЗ и КЗ по огромной 17-ой таблице.)

Жесть конечно. 2 Гига это примерно пара мульонов контрагентов (или документов не знаю что у вас там в отчете). В Эксель все влазит? Если с утра запустили к обеду успевает построиться?

Сейчас работает около 6 часов. Excel файл небольшой, но почти все ячейки собираются из фин.книги по своему алгоритму.

[ОльгаМ]

Один Аутомейшн
Каждый раз создается и каждый раз в конце чистится:

adocon.Close;
CLEAR(adocon);
Вынесла его запуск в отчет. Отчет запускала в режиме RUNMODAL- то же самое.

[rmv]

Да и нет особой разницы между deleteall(false) в Наве и приведенным SQL запросом.

[Constantine_imported]

А если запрос засунуть в хранимую процедуру и запускать её из НАВа? Хотя это костыль в некотором роде.

[ОльгаМ]

Цитата:

Сообщение от Constantine

А если запрос засунуть в хранимую процедуру и запускать её из НАВа? Хотя это костыль в некотором роде.

Увы, в хранимой процедуре я уже с этим столкнулась.

[ОльгаМ]

Пробовала и SLEEP ставить, и Adocon.BeginTrans и Adocon.CommitTrans, результат ноль.

[rmv]

Нет никакой разницы между delete from table на SQL и rec.deleteall(false) в Наве.

[ОльгаМ]

Цитата:

Сообщение от rmv

Нет никакой разницы между delete from table на SQL и rec.deleteall(false) в Наве.

В SQL быстрее отрабатывает, но лучше использовать truncate.
Какая-та опция должна быть, которая сбросила бы историю удаления.
Пробовала следующий оператор, но, увы, и он не сработал:

В цикле:

ConnectSQL();
_TableName := STRSUBSTNO('[dbo].[%1', COMPANYNAME) + '$Debts Forma 5 Buffer]';
strSQL := STRSUBSTNO('USE [%1]; SET LOCK_TIMEOUT -1;',DatabaseName);
strSQL += 'declare @str varchar(4000)';
strSQL += ' set @str = ''TRUNCATE TABLE with(TABLOCK) ''+' +'''' + _TableName+ ''''+ '' +
'+ '' DBCC CHECKIDENT (''+' +'''' + _TableName+ ''''+ '+'', RESEED,1);''' + ' exec (@str)'

MESSAGE('%1_begin',DebtsBuffer.COUNT);
adocon.Execute(strSQL);
MESSAGE('%1_end',DebtsBuffer.COUNT);
adocon.Close;
adocon.Cancel; // всё, что есть, всё использовала, чтобы сбросить adocon.Open.
CLEAR(adocon);

[rmv]

Цитата:

Сообщение от helga7289

Сейчас работает около 6 часов. Excel файл небольшой, но почти все ячейки собираются из фин.книги по своему алгоритму.

Так может проблему 6 часов решать а не чистить гигантский буфер?

Цитата:

Сообщение от helga7289

В SQL быстрее отрабатывает, но лучше использовать truncate.
Какая-та опция должна быть, которая сбросила бы историю удаления.
Пробовала следующий оператор, но, увы, и он не сработал:

Про truncate это сарказм был. Почитайте про права, требуемые для truncate.
Касаемо deleteall(false) в Наве и delete from table на SQL - скорость выполнения в один момент времени абсолютно одинаковая, код Нава транслируется в приведенный код SQL.
Возможно Вам стоит подучить матчасть прежде чем лезть грудью на амбразуру, подумайте о тех несчастных, что будут после Вас поддерживать код.

[AnDr]

Цитата:

Сообщение от helga7289

Цитата:

Сообщение от rmv

Нет никакой разницы между delete from table на SQL и rec.deleteall(false) в Наве.

В SQL быстрее отрабатывает, но лучше использовать truncate.
Какая-та опция должна быть, которая сбросила бы историю удаления.
Пробовала следующий оператор, но, увы, и он не сработал:

В цикле:

ConnectSQL();
_TableName := STRSUBSTNO('[dbo].[%1', COMPANYNAME) + '$Debts Forma 5 Buffer]';
strSQL := STRSUBSTNO('USE [%1]; SET LOCK_TIMEOUT -1;',DatabaseName);
strSQL += 'declare @str varchar(4000)';
strSQL += ' set @str = ''TRUNCATE TABLE with(TABLOCK) ''+' +'''' + _TableName+ ''''+ '' +
'+ '' DBCC CHECKIDENT (''+' +'''' + _TableName+ ''''+ '+'', RESEED,1);''' + ' exec (@str)'

MESSAGE('%1_begin',DebtsBuffer.COUNT);
adocon.Execute(strSQL);
MESSAGE('%1_end',DebtsBuffer.COUNT);
adocon.Close;
adocon.Cancel; // всё, что есть, всё использовала, чтобы сбросить adocon.Open.
CLEAR(adocon);

А есть понимание того, чем отличается и почему TRUNCATE TABLE отрабатывает быстрее DELETE? />/>/>

Вы раскладывали свой запрос (то, что получается в переменной strSQL) в студии SQL? В каком-то из предыдущих постов вам советовали это сделать. Если бы вы это сделали часть вопрос снялся бы сама собой.

1.В инструкции TRUNCATE TABLE не используется никаких хинтов, типа WITH (хинт)! Синтаксис truncate'a очень примитивный. Если вы напишите подобный sql код в студии SQL у вас полезут ошибки.

2. В инструкции DELETE, которая в первом посте - тоже самое! Подсказка (hint), если мне изменяет память, пишется после слова FROM, но никак не перед ним!

3. С плюсиками ('+') в запросе, вы тоже что-то "нахимичили", по-моему. Опять же если ваш запрос попытаться выполнить в студии - получится примерно такая вещь - DELETE (хинт!!!) FROM + (лишний плюсик) [Debts Forma 5 Buffer].

4. Мне кажется вообще не нужно заморачиватся с динамическим запросом. Разложите задачу на подзадачи, код сразу станет понятней и будет ясно где и что искать

И еще такой вопрос - зачем вы используете TABLOCK при удалении из таблицы? По-моему это просто бессмысленно.

Из этого делаю простой вывод - код на sql не отработает ни разу! Не то, что на второй раз...

P.S. По крайней мере тот код, который вы в качестве примера привели в постах.

[ОльгаМ]

<<зачем вы используете TABLOCK при удалении из таблицы? По-моему это просто бессмысленно.>>
Без этой опции отчет блокирует сам себя!

Спасибо всем, кому не безразлично оказалась моя проблема.
Отбросила идею удаления буферного файла через SQL.
Отчет переделала. Теперь вместо 6 часов выполняется 2 часа.
Построила 2 Аналитических Отчета и вместо Фин.Книги операций работаю с данными Аналитических Отчетов.

[artkashin]

Заполняете
strSQL
Вызываете
_strSQL

Где по середине код, работающий с _strSQL?
Также, используется переменная DatabaseName, уверены, что корректно отрабатывает?
В дебагере смотрели значение _strSQL перед запуском во второй раз?

[ОльгаМ]

Кстати, с этой проблемой столкнулась при формировании Аналитических Отчетов. Сам расчет Аналитических Отчетов предусмотрен в хранимой процедуре.
К сожалению, чистку необходимой буферной таблицы пришлось предусмотреть в Navision.