Пишу проект с использованием RadStudio XE 10.1. Обращаюсь к базе данных в формате Microsoft Access через ADO.
В базе данных хранится кривая с большим количеством точек(больше миллиона).
Данные в базе должны обновляться(сначала удаление, затем вставка новых данных), для удаления используется запрос вида:

Query = "DELETE FROM [DeviceData] WHERE [DeviceId] = " + String(DeviceId);

При выполнении запроса на удаление происходит "зависание" более чем на 2 минуты. При этом запрос на добавление аналогичной записи вида:

INSERT INTO

происходит значительно быстрее - около 20 секунд.
Зависание наблюдается только в готовом exe-файле(не важно debug или release версия), при работе в среде данный баг не проявляется. При этом на одних машинах зависание проявляется, на других удаление происходит почти мгновенно.

С чем может быть связано данное подвисание?

Прикрепляю тестовый проект. Ссылка на файл базы:
https://cloud.mail.ru/public/2Qio/GmEvffzTg

ПЕНСИОНЕРКА,

Все верно, запись одна. При ее удалении и происходит зависание

Народ,очень нужна помощь в решении этой проблемы. Месяц не можем понять в чем дело.

sdku,

1. "+" - так исторически сложилось. А разве это как-то влияет на текст запроса?
2. В коде String - конструктор класса строки, достаточно одного аргумента: UnicodeString(const char* src).
А String в Embarcadero С++ - это псевдоним UnicodeString:
typedef UnicodeString String

sdku,

Логика кода - удалить существующую и потом добавить новую строку в таблицу DeviceData. Удаление обычным запросом DELETE FROM происходит более 3-х минут, последующий INSERT INTO тех же данных в записи - 20 секунд. Проблема - долгое удаление записи.

sdku,

В рабочей базе конечно не одна. Это для публикации я подготовил тестовый пример, где оставил только одну запись.

Прикрепил скриншот со временем удаления

sdku,

Удалить из таблицы [DeviceData] записи, в которых поле [DeviceId] = 1. Здесь String(DeviceId) - преобразование целочисленного значения в текст.

1-я строка обработчика Button1Click:
int DeviceId = 1;

sdku,

Так ОК?
Query = "DELETE FROM [DeviceData] WHERE [DeviceId] = " + IntToStr(DeviceId);

vmag,

От битности не зависит, может проявляться и там и там. От мощности машины тоже.

vmagв С++ это случаем не 100 секунд?

Это миллисекунды:
VOID WINAPI Sleep(
_In_ DWORD dwMilliseconds
);

Закомментировал строки с #include <dinkumware64/chrono> ... std::chrono и Sleep(100); - ситуация не изменилась.

sdku,

Это и есть реальная таблица, только с одной записью.
Вот запрос и значение переменной Query:

where,

В этом случае "зависание" пропадает

sdkuтогда напишите при совершении какого действия (нажатие кнопки или чё другое) Вы хотите удалить запись.
Да, при нажатии кнопки нужно удалить запись с известным DeviceId (в данном случае DeviceId = 1)

sdkuИ все же ответьте: каков критерий отбора записей для удаления?
Критерий только один - в строку формирования запроса на удаление передается DeviceId.

vmagа если в схеме данных удалить связь между таблицами и вернуть WHERE ? просто интересно... ну или для этого случая вообще оставить только одну таблицу DeviceData, просто интересно, что за хренотень такая...
Пробовал уже. И связь удалял, и индексы

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]Приведенный пример скорее исключение, в основном объем данных в каждой записи много меньше.

MrShinА какой сейчас размер файла с базой? При налчии поля с двоичными данными очень быстро можно достигнуть предела в 2 Гб, после чего начинаются ошибки, тормоза и прочие чудеса.

Или у вас тормозит даже на одной записи на файле, который вы выложили?Размер тестовой БД - 35 МБ

Vladimir Baskakovпоказать сишный код. Вот прямо как написан . И оттрассировать )))))
Тестовый проект прилеплен к первому топику, вот кусок кода на удаление. Зависает на ADOCommand->Execute(), после отвисания переходит на строчку с while

vmagМожете не пробовать... я в этой своей бд запустил ваш запрос и получил ваше время удаления больше 2-минут... Машина очень шустрая, W7 (64), акцесс 2003... жють... даже без where на OLEУже попробовал - зависает. Хотя идея была хорошая

vmagSynton,
У меня такое ощущение, что перед удалением система пробует искать всё, что есть в системе, связанное с объектом в OLE и если на машине ничего нет, то она долго думает чо с этим объектом делать чтобы правильно его покоцать... не? ну или наоборот - если что-то есть... А что там лежит, если не секрет?Я грешу на какой-нибудь процесс "дефрагментации" памяти или пересборку индексов ядром Access, и что этот процесс зависит от ОС (на Win10 не зависает). Данные - кривая замера параметра во времени