Глюк В ADO - Adotable перемешивает записи в таблице

Модераторы: Duncon, Naeel Maqsudov, Игорь Акопян, Хыиуду

namomelkor
Сообщения: 230
Зарегистрирован: 31 авг 2006, 13:11

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

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

и при таком перемешивании таблицы получается дублированный индекс.
как это исправить.
Siniy
Сообщения: 1
Зарегистрирован: 02 мар 2007, 14:38

А зачем такие сложности?
Если id-поле типа счетчик, то команда ADOTable1.Insert автоматически увеличивает счетчик.
namomelkor
Сообщения: 230
Зарегистрирован: 31 авг 2006, 13:11

счетчик незьзя обнулить кроме как удалением и созданием таблицы заново а этого делать нельзя.
Просто получится что счетчик вылезет за пределы integer;
Аватара пользователя
SergeyS
Сообщения: 196
Зарегистрирован: 21 ноя 2006, 17:12
Откуда: Хакасия, Абакан
Контактная информация:

Просто получится что счетчик вылезет за пределы 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]). Данный запрос позволит тебе находить индекс удаленных записей, что даёт возможность экономно использовать уникальные номера.
Absurd
Сообщения: 1228
Зарегистрирован: 26 фев 2004, 13:24
Откуда: Pietari, Venäjä
Контактная информация:

namomelkor писал(а):счетчик незьзя обнулить кроме как удалением и созданием таблицы заново а этого делать нельзя.
Просто получится что счетчик вылезет за пределы integer;
Не вылезет. В языке С текущее время измеряется в секундах от запуска первой UNIX системы (январь 1970), счетчик 32-битовый, но его хватит еще очень надолго. Сканировать таблицу на предмет неиспользуемых идентификаторов категорически нельзя из соображений масштабируемости.
2B OR NOT(2B) = FF
namomelkor
Сообщения: 230
Зарегистрирован: 31 авг 2006, 13:11

люди вы не вту сторону начали думать.
короче вроде разобрался в чем глюк
поставил динамические курсоры и на всекий случай еще и серверный тип курсора(на время).
Раньше был статический курсор и данные в table не обновлялись при изменении таблицы другими клиентами как я понял из-за этого и глючило.
Аватара пользователя
Игорь Акопян
Сообщения: 1440
Зарегистрирован: 13 окт 2004, 17:11
Откуда: СПБ
Контактная информация:

по-любому, если у тебя ключевое поле будет определяться методом select max(id)+1 - жди проблем при количестве подключений к базе > 1
Изображение
namomelkor
Сообщения: 230
Зарегистрирован: 31 авг 2006, 13:11

подключей нет и не будет
Аватара пользователя
Игорь Акопян
Сообщения: 1440
Зарегистрирован: 13 окт 2004, 17:11
Откуда: СПБ
Контактная информация:

namomelkor, речь шла про подключеНИЯ ;)
Изображение
namomelkor
Сообщения: 230
Зарегистрирован: 31 авг 2006, 13:11

Игорь Акопян писал(а):namomelkor, речь шла про подключеНИЯ ;)
Сорри пропустил. ПодключиНИЙ да действительно много
Ответить