Проблема в ADO

← →
Мунька (2004-05-04 19:14) [0]

Для доступа к данным MS Access использую компонент TADOQuery. Проблема в следующем. Формирую SQL-запрос на удаление данных из таблицы, даю его на выполнение, естественно, что следующий шаг - отображение оставшихся данных. Вот тут и возникает проблема - при выполнении запроса SELECT * и т.д возвращается столько же данных, сколько и было до удаления. То есть результат удаления виден только, если я вручную нажимаю на своей форме кнопку "Обновить" (которую сама делала). Проблему я обходила лишь в том случае, когда между DELETE и SELECT проходило определенное время, около 2 секунд (Sleep(2000) ). Может быть есть другие возможности? Вместе с TADOQuery использую TADOConnection, поскольку без него вообще мрачно.

← →
sniknik © (2004-05-05 00:19) [1]

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

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

← →
SergP © (2004-05-05 00:27) [2]

Хм... работаю тоже с Access через ADO
Но таких проблем еще не возникало
а удаляю я так:
AdoConnection1.Execute("delete ..... ");

просто так удобнее...

← →
Курдль © (2004-05-05 00:43) [3]

а удаляю я так:
Format C:
просто так удобнее...

← →
sniknik © (2004-05-05 00:58) [4]

SergP © (05.05.04 00:27) [2]
проверь с двумя компонентами ADOCommand1 для удаления и ADODataSet/ADOQuery для запроса, но только без ADOConnection(!!!) в одном или лутше в обоих случаях, вместо этого строку коннекта прям в компонентах пропиши, будет то что описано. (и то 2сек чегото много)

Курдль © (05.05.04 00:43) [3]
да ты просто высокочастотное излучение на диск не пробовал! гораздо удобнее, и чище. ;о)

← →
SergP © (2004-05-05 01:37) [5]

>sniknik © (05.05.04 00:58)

Может быть... не пробовал, да и я вам верю на слово...
Только вот как я понял, вопрошающий все-таки юзает ADOConnection

>Курдль © (05.05.04 00:43)
Ну это вообще круто...

Хотя можно еще и нагреть винт до температуры Кюри. Быстрее будет. Например кинуть его в емкость с расплавленным железом... А то FORMAT C: долго выполняется...

← →
sniknik © (2004-05-05 01:42) [6]

> Только вот как я понял, вопрошающий все-таки юзает ADOConnection
тоже так думаю, да и написал он об этом, но всетаки как то не правильно юзает если такие тормоза.

← →
Мунька (2004-05-05 11:06) [7]

Дело в том, что на SELECT и DELETE действительно два разных ADOConnection - просто один, тот что на SELECT - в одной форме, а на DELETE - в другой, правда, та форма модальная - пока не удалит или не отменит действие SELECT недоступен.
Код выглядит так
извлечение
bool __fastcall TMainForm::SelectHistory(int UserId, int DeviceId)
{
try{
if(ADOQueryHistory->Active)
ADOQueryHistory->Close();
}
catch(...)
{ return false;}

ADOConnectionHistory->Connected = false;
ADOConnectionHistory->ConnectionString = ConnectionADO;
ADOConnectionHistory->Connected = true;
ADOQueryHistory->Connection = ADOConnectionUser;
ADOQueryHistory->SQL->Clear();

ADOQueryHistory->SQL->Add("SELECT * FROM TableHistory" );
ADOQueryHistory->SQL->Add("WHERE UserId =" + IntToStr(UserId) );
if (DeviceId!=-1)
ADOQueryHistory->SQL->Add("AND DeviceId =" + IntToStr(DeviceId) );
try{
if(!ADOQueryHistory->Prepared )
ADOQueryHistory->Prepared = true;
ADOQueryHistory->Open();
}
catch(...)
{
return false;
}

return true;
}
//Далее - процедура вызова формы определения критериев удаления
void __fastcall TMainForm::ADeleteHistoryExecute(TObject *Sender)
{
FormDeleteHistory->UserId = UserId;
FormDeleteHistory->L_SecFirstName->Caption = UserSecondName + " " +UserFirstName;
FormDeleteHistory->LMiddleName->Caption = UserMiddleName;
if(FormDeleteHistory->ShowModal()==mrOk)
{
//Вторая задержка
Sleep(800);
SetDefSG_History();
if (!SelectHistory(UserId) )
return;
InputHistoryToGrid();
SG_History->Invalidate();
}
}
//И процедура удаления в FormDeleteHistory
void __fastcall TFormDeleteHistory::SB_DeleteClick(TObject *Sender)
{
TDateTime BDT, EDT;
AnsiString sqltxt = "DELETE FROM TableHistory " + AnsiString("\n");
int dev_id = 0;
if (RB_PartHistory->Checked&&!CB_DateTime->Checked&&!CB_Device->Checked)
{
MessageDlg( MsgCriteriaDelete, mtInformation, TMsgDlgButtons() << mbCancel, 0);
return;
}
if (CB_DateTime->Checked)
FormDateTimeInterval(BDT, EDT);
if(CB_Device->Checked)
if (cmb_Device->ItemIndex>=0 )
dev_id = cmb_Device->Items->Strings[cmb_Device->ItemIndex].ToIntDef(0);

//Формирование строки запроса
sqltxt = sqltxt + "WHERE UserId =" + IntToStr(UserId);
if (RB_PartHistory->Checked)
{
//Ïî äàòå
if(CB_DateTime->Checked)
sqltxt += " AND (DateTimeEvent BETWEEN :DTEB AND :DTEE) ";
//Если еще и устройство выбрано
if(CB_Device->Checked)
sqltxt += " AND DeviceId = " + IntToStr(dev_id);
}
//Ожидающий курсор на форм
Cursor = crSQLWait;
ADOConnectionDel->Connected = false;
ADOConnectionDel->ConnectionString = ConnectionADO;
ADOConnectionDel->Connected = true;
ADODelHist->Connection = ADOConnectionDel;
if (ADODelHist->Active)
ADODelHist->Active = false;

ADODelHist->SQL->Clear();
ADODelHist->SQL->Add(sqltxt);
try
{

if(CB_DateTime->Checked)
{
ADODelHist->Parameters->ParamByName(WideString("DTEB"))->Value = BDT;
ADODelHist->Parameters->ParamByName(WideString("DTEE"))->Value = EDT;
}
if (!ADODelHist->Prepared)
ADODelHist->Prepared = true;
ADODelHist->ExecSQL() ;
ADOConnectionDel->Connected = false;
}
catch(...)
{
ModalResult = mrCancel;
return;
}
//Первая задержка, сразу после удаления
Sleep(1000);
ModalResult = mrOk;
}

Без первой и второй задержек не работает толком.

← →
sniknik © (2004-05-05 11:17) [8]

> Дело в том, что на SELECT и DELETE действительно два разных ADOConnection
ну раз причина ясна то что сделать надо? правильно исправить. про модули данных в курсе?

← →
Мунька (2004-05-05 11:23) [9]

Конечно в курсе.. только что-то там тоже было не очень хорошее - в предыдущей программе, поэтому и отказалась от них..а вспомнила тогда вопрос есть 100 процентная гарантия, что TADOConnection не расконектиться сам по себе, то есть я ему дала
ADOConnectionDel->Connected = true, а он вдруг станет false?
И еще, если вдруг ADOConnectionDel->Connected == false, то что станет с открытыми активными TADOQuery (я имею ввиду те запросы, которые и держу открытыми, там где был какой-либо SELECT)?

← →
Мунька (2004-05-05 11:36) [10]

Такс проверяем... удаление и выборка на одном коннекте

> что TADOConnection не расконектиться сам по себе

А с чего это вдруг ему должно захотеться расконектиться самому по себе?

← →
Мунька (2004-05-05 13:24) [12]

С того же, с чего такие тормоза на разных коннектах. Сейчас пишу еще одну процедуру удаления из двух таблиц - сначала с подчиненной, затем с главной, вот и проверю, как себя все поведет на одном конекте. Кстати, вроде проблема уходит. Но.. вот что удивительно, без объекта TADOConnection, через строку коннекта - мрачно все (из опыта другой программы), как только в таблице 2 записи SELECT их не видит.

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

Проблема в ADO Найти похожие ветки