Если я правильно понял, то после rs.AddNew() rs("id") будет равен id этой записи?
Ой не факт что именно так

Лучше

Саныч, по-твоему получается, что

будет инкрементировать счетчик?
Хм, может и так... Проверю.

Да, чего-то я стормозил...
Действительно так

2 Geo
Сегодня среда

Несмотря на то, что сегодня среда, считаю более правильным опряделять ID добавленной записи после собственно добавления, а не до.
Не доверяю я этим счетчикам... Особенно после того, как начал регулярно наблюдать дублирование значений (в случае если индекс уникальный отсутствует).
Хз - когда там аксес новый номер получает, когда он его резервирует, не поменяет ли он его в момент .Update...

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

2 Bor-L
И ты уверен, что оно не поменяется в момент добавления?
Для этого надо четко себе представлять, как именно работает аксес со счетчиками. И быть уверенным, что этот механизм не изменится с каким-нибудь сервиспаком. У меня нет ни четкого представления (так, могу что-то додумать от себя), ни уверенности.

Запись, еще не добавленная в таблицу - можно считать еще не существует. ID-шник несуществующей записи - смысла не имеет.

У меня, например, так формируется уникальное поле "Id.НомерФилиала"
Ну а это уже совсем непонятное решение. Зачем так нужно? Ну да и хрен бы с ним. К теме мало относится

Кажись я начинаю выздаравливать
Вот что значит дружеская поддержка

Да никакая это не передозировка.
Аксес при добавлении записи в таблицу со счетчиком, очевидно, выполняет следующие шаги:
1. Получить новый ID
2. Инкриментирует значение счетчика в таблице.

Как показывает практика, на этапе 1 разные пользователи могут получить одинаковое значение - в случае если уникальный индекс не стоит. При этом действительно добавляются разные записи с одинаковым значением в поле типа счетчик.
Как показывает та же практика - если стоит уникальный индекс, то дублирования первичного ключа не наблюдается (хотя и такое у меня бывает, причем только со счетчиками ).

Внимание вопрос - в случае наличия уникального индекса аксес а) под другому получает ID (с дополнительной блокировкой) или б) в момент Update'а выполняет все необходимые проверки на значения (которые он и так выполняет, независимо ни от каких счетчиков), и, если счетчик продублировался, то еще раз получает ID?

Если кто-нибудь способен на этот вопрос ответить со ссылкой на какие-нибудь источники - то вперед. Я могу только строить предположения, которые ничем доказать не получается. Поэтому предпочитаю ID-шник добавленной записи определять уже после добавления, а не в процессе.

2 Сенин Виктор
Если бы все было так пушисто как ты описываешь - я бы и не парился.
Однако (блин, в третий раз за один топик повторяю) - периодически наблюдал дублирующиеся счетчики. Значит не все так пушисто.

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

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

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

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

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

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

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

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

2 Саныч
UpdateBatch?

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

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

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

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