vboretsТригеры в базе на удаление в таблице есть?
Индекс?
Триггеров нет, индекс на поле deviceid

sdkuSynton,
вопрос подкупающий своей наивностью:
-а как через форму добавить запись в тбл.Device и вообще её предназначение?
-какие данные в поле MeasData и как они туда заносятся?
Как эти вопросы связаны с решением проблемы?

whereА запрос
тоже долго выполняется?
Именно этот запрос как раз долго и выполняется.

Я понимаю, что долгое выполнение как-то связано с тем, что в единственной записи в таблице DeviceData поле MeasData (OLE-объект) содержит данные размером 35 МБ. Если в это поле записать небольшой объем - время выполнения нормальное (доли секунды).
При этом выполнение запроса на удаление в консоли самой БД происхолит быстро, также быстро, как выполнение удаления в программе, запушенной в среде RAD Studio. Зависает именно при запуске exe-шника.

whereНо определяться нужная запись будет с помощью WHERE (единственная запись в таблице лишь для примера).
А тормоза наблюдаются именно при WHERE, без WHERE тормозов нет.
Судя по рассказам ТС.
Все верно, на апдейте с условием WHERE также зависает

MrShinSynton,
Что-то мне сдается, что вопрос вообще не к Акцессу. Вы вообще на каком языке пишете на RadStudio? Сорри, базу не открывал. Думаю, вопрос лучше задать в профильный форум.
RAD Studio C++, доступ к БД через ADO компоненты. Настройкаи коннекта можно посмотреть в коде тестового проекта

MrShinЧтобы отделить мух от котлет, я бы провел простой эксперимент: в самой Акцессовской базе написал бы элементарную процедурку, которая через ADO удаляет строки по критерию.
Попробую, отпишусь

MrShinВ первом случае я бы еще проверил удаление через DAO или просто запросом из конструктора, если опять медленно, то виновата исключительно база.
Запрос из конструктора работает нормально, без задержек.
А есть пример построения запроса на удаление через DAO? Никогда не использовал этот интерфейс

SyntonwhereА запрос
тоже долго выполняется?
Именно этот запрос как раз долго и выполняется.

Я не внимательно прочитал вопрос - вношу поправку в свой ответ. SELECT FROM [DeviceData] WHERE [DeviceId] = 1 выполняется нормально (секунду где-то), зависает DELETE FROM [DeviceData] WHERE [DeviceId] = 1

MrShinЧтобы отделить мух от котлет, я бы провел простой эксперимент: в самой Акцессовской базе написал бы элементарную процедурку, которая через ADO удаляет строки по критерию.

Написал запрос на удаление записи по критерию через ADO - удаление моментальное:

Vladimir Baskakovа такой запрос, быстро или долго?
SELECT DeviceId FROM [DeviceData] WHERE [DeviceId] = 1
В смысле, если не тянуть мегаполе.Быстро. Даже если тянуть мегаполе - тоже быстро (секунда)
Vladimir BaskakovИ можно ли писать так
DELETE DeviceId FROM [DeviceData] WHERE [DeviceId] = 1
Писать так можно, но быстрее не стало.
Vladimir Baskakovотличаются ли машины где работа идет быстро и медленно установленными акцессами?Нет, от версии Access не зависит.
Зависает на Win7x64 с Access 2016, на Win7x64 с Access 2010, но, например, на Win10x64 с Access 2016 все быстро
Vladimir Baskakovкакая строка подключения в ADO - через какой драйвер?String DatabaseFile = "d:\\test2.mdb";
String ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + DatabaseFile + ";Persist Security Info=False";
Vladimir Baskakovможно ли данные, которые лежат в огромном поле класть в файлы рядом с БД, а в БД хранить только имена файлов - не станет ли лучше? и удалять файл одновременно с удалением записи.Нет, не прокатит, архитектурой приложения этого не предусмотрено. Все в одном файле БД Access

Vladimir BaskakovЧто работает долго - сам делит, или закрытие транзакции с коммитом? Как это проверить в С++?

Мне думается, что БД Access не самое лучшее место для закладки больших объемов данных.[/quot]Приведенный пример скорее исключение, в основном объем данных в каждой записи много меньше.