Developing.ru

есть аксесовская база к которой я подключаюсь через АДО и добавляю данные.
на определенном этапе ADOTABLE начинает отображать таблицу в перемещаном виде т.е сначала данные распологаются в порядке их добавления в базу
1
2
3
4
5
6
7
а потом на какомто этапе получается
4
5
6
7
1
2
3

для новой записи я определяю индекс по последней записи т.е
ADOTable1.Last;
id:=ADOTable1.Fields[0].AsInteger+1;

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

А зачем такие сложности?
Если id-поле типа счетчик, то команда ADOTable1.Insert автоматически увеличивает счетчик.

счетчик незьзя обнулить кроме как удалением и созданием таблицы заново а этого делать нельзя.
Просто получится что счетчик вылезет за пределы integer;

Просто получится что счетчик вылезет за пределы integer

Был период, когда я тоже так считал но даже если ты будешь в базу непрерывно добавлять 1 запись в секунду то достигнешь максимального значения Integer только за 68 лет (1 * 60сек * 60мин * 24час * 365 дн * 68 лет = 2 144 448 000), а ведь можно использовать не integer a int64 .
Учитывая что это у тебя база данных Access то будет скорее как говаривал Хаджа Насредин "... или осел заговорит или падишах умрёт..."

А если серьёзно, то получение нового индекса возможно следующими способами (возможно есть и другие)
1. Использование счетчика (наиболее удачный способ)
2. Использование запроса к базе: select max(id) from [table] - по суте тот же счетчик (ты думаешь записи у тебя будут удаляться только с конца?)
3. Использование запроса к базе: select min(id+1) from [table] where (id + 1) not in (select id from [table]). Данный запрос позволит тебе находить индекс удаленных записей, что даёт возможность экономно использовать уникальные номера.

namomelkor писал(а):счетчик незьзя обнулить кроме как удалением и созданием таблицы заново а этого делать нельзя.
Просто получится что счетчик вылезет за пределы integer;

Не вылезет. В языке С текущее время измеряется в секундах от запуска первой UNIX системы (январь 1970), счетчик 32-битовый, но его хватит еще очень надолго. Сканировать таблицу на предмет неиспользуемых идентификаторов категорически нельзя из соображений масштабируемости.

люди вы не вту сторону начали думать.
короче вроде разобрался в чем глюк
поставил динамические курсоры и на всекий случай еще и серверный тип курсора(на время).
Раньше был статический курсор и данные в table не обновлялись при изменении таблицы другими клиентами как я понял из-за этого и глючило.

по-любому, если у тебя ключевое поле будет определяться методом select max(id)+1 - жди проблем при количестве подключений к базе > 1

подключей нет и не будет

namomelkor, речь шла про подключеНИЯ

Игорь Акопян писал(а):namomelkor, речь шла про подключеНИЯ

Сорри пропустил. ПодключиНИЙ да действительно много