Автоинкреминируемое поле в STANDART PARADOX7

← →
DmitrichJ (2007-04-23 21:58) [0]

Как узнать последнее значение автоинкреминируемом поле в этой СУБД? Чтобы была гарантия стабильной работы в небольшой сети. Спасибо

← →
Johnmen © (2007-04-23 22:34) [1]

> гарантия стабильной работы в небольшой сети

Это фантастика. Причём ненаучная.

← →
MsGuns © (2007-04-23 23:39) [2]

>Johnmen © (23.04.07 22:34) [1]
>Это фантастика. Причём ненаучная

Никогда не говори "никогда". (с)

← →
Loginov Dmitry © (2007-04-24 07:53) [3]

> Как узнать последнее значение автоинкреминируемом поле

SELECT Max(Автоинкрементное_поле) FROM Таблица

← →
Виталий Панасенко © (2007-04-24 09:17) [4]

Обычно это поле делаеют ключевым.. Сделать активным ПК и переместиться на последнюю запись. Хотя смысл ? При добавлении (TTable) драйвер Парадокса сам вернет новое сгенерированное значение..Хотя бывают глюки(при падении ПО, сиситемы, отключении эл.питания): генерится повторное значение.. Сам натыкался...

← →
Jeer © (2007-04-24 09:52) [5]

> DmitrichJ (23.04.07 21:58)
>
> Как узнать последнее значение автоинкреминируемом поле в
> этой СУБД? Чтобы была гарантия стабильной работы в небольшой
> сети. Спасибо

А зачем его узнавать ?

Надежнее сделать id не autoinc, но PK.

Например так:

function quGetNextId_(tbName,vFieldName: String): LongInt;
begin
with TQuery.Create(nil) do
try
DatabaseName := DBname;
SQL.Add("SELECT MAX("+vFieldName+") FROM " + tbName);
Open;
result := Fields[0].AsInteger + 1;
Close;
finally
Free;
end;
end;

Затем конкурентная попытка вставки записи с этим id заданное число раз.
Проверено давным давно и многократно.
Работает.

Могут быть заморочки в случае уникальных индексов, но в частных случаях это удается разрулить.

← →
ЮЮ © (2007-04-24 11:39) [6]

> Затем конкурентная попытка вставки записи с этим id заданное
> число раз.

Можно и без "заданное число раз" а до тех пор пока quGetNextId после неудачной вставки отличается от того, что мы пытались вставить. Тогда проблема вставки может быть объяснена именно этим. Если же ошивка вставки имеет место, а quGetNextId = вставляемому значению, то проблема вставки явно не из-за этого и можно "вываливаться" из цикла попыток вставки записи.

← →
Jeer © (2007-04-24 11:58) [7]

> ЮЮ © (24.04.07 11:39) [6]

Разумеется:)
В реальности было
1: получение NextId
2: попытка вставки 2-3 раза
3: rpt 1: 2-3 раза

Между вставками sleep на 20-40 ms в зависимости от сети, винтов, кол-ва юзеров и пр.

При полной неудаче - msg юзеру.

Такой метод проверялся на имитационных испытаниях в сетке до 20 машин
с разными интервалами вставки записей и их количества и велся подробный лог на каждой станции.

Результаты испытаний превзошли все ожидания и метод получил путевку в жизнь.
Правда это был не Paradox, а DBISAM от elevatesoftware (DBE встраиваемая в exe), но не суть.
Было это где-то в 94-95 г., но метод от этого не прокис, полагаю.

Так, что если очень хочется, то можно.

← →
DmitrichJ (2007-04-24 13:36) [8]

> SELECT Max(Автоинкрементное_поле) FROM Таблица

Это только для локальной БД.

Jeer, не уверен, что это будет работать стабильно. Покрайней мере в IB это точно не работает в сети, но идея понятна. Может для 2-3 юзеров стоит подумать.

← →
Jeer © (2007-04-24 13:53) [9]

> Jeer, не уверен, что это будет работать стабильно. Покрайней
> мере в IB это точно не работает в сети,

Это работает для любого типа СУБД, даже для ORACLE:))

← →
Gadenysh (2007-04-24 14:07) [10]

> Покрайней мере в IB это точно не работает в сети, но идея
> понятна.

еще как работает. толко нахрена? в IB есть генераторы - они рулят

← →
Jeer © (2007-04-24 14:14) [11]

> еще как работает. толко нахрена?

Зависит от задачи.
Например, для небольшого по пользовательской нагрузке проекта Заказчик заложил 8 типов используемых СУБД - от Paradox до Oracle.
И что, под каждую реализацию писать свой шлюз ?
Понятно, что пример несколько притянутый, но в принципе - так.

← →
DmitrichJ (2007-04-24 18:44) [12]

"SELECT MAX" в IB по сети, если добавляют одновременно, то он выдаст 2 одинаковых значения.

← →
ANB © (2007-04-24 18:59) [13]

> Это работает для любого типа СУБД, даже для ORACLE:))

В оракле за такие шутки программеров обычно кастрируют.

← →
Jeer © (2007-04-25 13:02) [14]

> DmitrichJ (24.04.07 18:44) [12]
>
> "SELECT MAX" в IB по сети, если добавляют одновременно,
> то он выдаст 2 одинаковых значения.
>

Это не важно, т.е. конкуренция будет на вставке.

> В оракле за такие шутки программеров обычно кастрируют.

На счастье остальных ORACLE далеко не всем нужен, кроме того никто не говорил, что это единственно верный и надежный метод.
Это скорее решение с вероятностным исходом для небольшой СУБД с малой активностью пользователей.

← →
Johnmen © (2007-04-25 13:09) [15]

> Jeer © (25.04.07 13:02) [14]
> никто не говорил, что это единственно верный и надежный метод.

Не единственный, но безусловно надёжный, не зависящий от СУБД.

> Johnmen © (25.04.07 13:22) [17]
<>
Существует зависимость от конкретной среды (OS, трасса, активное сетевое оборудование, винты, пользователи, задачи) - которая влияет на результат разовой операции вставки.
Подбирать автоматически - нет модели, но можно для конкретного случая настроить, чтобы работало почти без отказов.

При перезапросе пользователя на повторение операции - как правило все отрабатывает по штатному.

Был случай, когда мы с одного клиентского места имитировали массовую вставку записей в районе 200-300 тыс.
Отказы для ленивых пользователей возникали, но не более одного отказа на пользователя из 2-5 пользователей при их общем количестве 20 за все время импорта.

> Jeer © (25.04.07 14:08) [18]

Ну методика-то состоит не из одной разовой операции вставки.
Я утверждал [15] именно для методики, а не для отдельных её фрагментов...:)

> Johnmen © (25.04.07 14:11) [19]

Дело в том, что были случаи, но редкие, когда шел отказ от вставки даже при выполнении рекомендаций Jeer © (24.04.07 11:58) [7]
Юзеру вываливается мессага по необходимости повторения операции, которая со второго раза проходит. Двух случаев отказа мы не наблюдали.

> Jeer © (25.04.07 14:15) [20]
> Дело в том, что были
> случаи, но редкие, когда шел отказ от вставки даже при выполнении
> рекомендаций Jeer © (24.04.07 11:58) [7]

Как может быть отказ от вставки, если цикл крутится пока не вставим?

> Как может быть отказ от вставки, если цикл крутится пока
> не вставим?

Реализации могут быть разные, но мы тогда не стали делать бесконечный цикл, а ограничились 2-3 попытками вставки при одном и том же id, затем 2-3 внешних цикла по смене id и опять 2-3 попытки вставки.
Причем время между каждым внешним циклом увеличивали с 20 до 60 ms.

Вот когда и это все не срабатывает - называем отказ от вставки и передаем инфу юзеру "Повторить ?"
Вполне разумный механизм.

Автоинкреминируемое поле в STANDART PARADOX7 Найти похожие ветки