2 Сенин Виктор
Там где нет уникального первичного ключа? Дык у меня таких счетчиков и нет (и не было, да и не будет)
У меня такое тоже случайно возникло. Ну недоглядел чуток .
А так действительно - счетчик без уникальности просто нафиг не нужен.

Чуть раньше
Так что можно не париться, надо лишь отследить Error в случае ошибки сохранения и сбросить нафиг полученное значение.
Так можно и вообще тогда от счетчиков отказаться. Что я с успехом и практикую.

2 Саныч
Это значит, что счетчики могут дублироваться. Но это не значит, что в процессе добавления записи значение счетчика может меняться.
Но и не значит что не может. Как только делаешь уникальный индекс - все работает как надо. Значит, счетчик либо подругому получается (новое значение), либо запись по другому вставляется (с проверкой и переполучением счетчика).
Что именно происходит - мне неизвестно, ибо специально воспроизвести такую ситуацию не получается, никакие брекпоинты не помогают. Так что я и гадать даже не берусь.

2 Geo
И такое тоже есть. Добавление записи запросом с явным указанием значения счетчика - единственный известный мне способ управления этим значением. И все следующие записи будут получать значения счетчика начиная от добавленного значения.
Кстати, решил проверить последнее предложение - хрен там. В ХР-шном аксесе ID-шники продолжают вставляться с нормальными значениями, наплевав на добавленную запросом запись. Хотя в 97-м описанный эффект имеет место быть (сам видел). Так что какие-то отличия уже всплывают.

2 All
Не фиг. Или присваивать идентификаторы вручную, или, если уж мы отдаем это на откуп аксесу, то брать результаты его работы по ее завершению.

2 Geo
А я ни разу не смог специально увидеть, чтобы ему удалось два одинаковых счетчика получить. Вот как не бился и куда только точки останова не ставил - всегда он разные получает. А на живой базе - да пожалуйста. Причем база в конвульсиях не билась.
Так что если мы чего-то не можем сделать - не значит что аксес этого не может.

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

Имел счастье это наблюдать при какой-то хитрой схеме данных. Т.е. несколько таблиц, уникальные индексы по счетчикам, связи с обеспечением целостности по полям типа счетчик, формочки, висящие на этих таблицах. Точнее уже не вспомню сходу. При добавлении записей через форму - на BeforeUpdate брал текущее значение счетчика (из контрола на форме) и добавлял нужные записи в другую таблицу. Такой вот триггер для бедных .
Так вот. Если добавлялось сразу несколько записей (через буфер обмена) - при обращении к ID-шнику выдавалось сообщение о невозможности чтения ввиду установленной блокировки на чтение (!). У меня тогда глаза на лоб вылезли.
Пока с этим экспериментировал - выяснил, что если убить связь с обеспечением целостности данных, то все становится ок. Если добавлять записи по одной - тож все ок. А вместе - не живут, моя же формочка сама себе выставляет блокировку на чтение.
Это, конечно, экстремальные условия, но все же.

2 Саныч
UpdateBatch?

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

Господа, хрен знает как этот долбаный счетчик работает. Я, например, единственный раз в жизни увидел блокировку на чтение.
Стараюсь по возможности счетчиков избегать, но иногда лень берет верх :(

Не дополз до лестницы

Мааароооссс маааарроооооосс
Ннниии мааарроззьь мииняяаааа