Индивидуальные идентификаторы авто-нумерации для таблиц?

Есть ли способ использовать мой собственный номер в таблице как автоматический номер; то есть автоматически назначать следующей доступной новой записи. У нас есть системные идентификационные номера для каждого сотрудника, которого я хочу привязать к этой базе данных. Я просто хочу, чтобы таблица автоматически присваивала следующий номер.

Могу ли я это сделать?
Можно ли это сделать с помощью комбинации цифр и букв?
Можно ли использовать критерии, например, код A = определенный набор чисел, код B = другой?


person Justin    schedule 14.12.2009    source источник


Ответы (2)


Конечно, можете, но вам придется спроектировать это самостоятельно.

Есть сотни способов сделать это, но один из них может заключаться в том, что у вас может быть таблица параметров с «nextQuote», «nextEmployeeNo», «nextJob» ... конечно, ваш дизайн таблицы может иметь что угодно, включая пример префикса;

PARAMETERS
Prefix    Number
Q          1145
E            54
J           999

Итак, теперь вы можете SELECT PreFix + MAX(Number) AS NextEmployee FROM Parameters WHERE Prefix = E

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

UPDATE Parameters SET Number = number + 1 WHERE Prefix = E 

Если это не подходит для работы, надеюсь, это заставит вас задуматься о том, как вы можете сделать что-то подобное.

Надеюсь это поможет.

person CaRDiaK    schedule 14.12.2009
comment
да, я думаю, это приведет меня в правильном направлении. Спасибо! - person Justin; 14.12.2009

Для пользователей ADO:

Как реализовать многопользовательские настраиваемые счетчики в Jet 4.0

Для пользователей DAO:

Как реализовать многопользовательские настраиваемые счетчики в DAO 3.5

person onedaywhen    schedule 14.12.2009
comment
К сожалению, в статье, которую вы цитируете, используются ADO и JRO, две технологии, которые действительно не нужны при работе с хранилищами данных Jet / ACE. В этой статье показано, как сделать то же самое в DAO: support.microsoft.com/kb / 191253 / EN-US - он не требует дополнительных ссылок или позднего связывания и на 100% эквивалентен версии ADO / JRO (т. Е. Делает то же самое с движком Jet db). - person David-W-Fenton; 15.12.2009
comment
Я воздержусь от редактирования и оставлю свой комментарий в силе просто потому, что для его повторного редактирования, чтобы он был сформулирован надлежащим образом, я бы удалил все содержимое вашего сообщения и заменил его своим, поскольку версия ADO в значительной степени неактуальна для Контекст доступа. - person David-W-Fenton; 16.12.2009
comment
Во-первых, в вопросе нет ничего, что указывало бы на то, что контекст является чем-то другим, кроме ядра СУБД Access. Во-вторых, технологии, которые действительно не нужны, а версия ADO в значительной степени неуместна, являются просто аргументами: ADO против DAO и все такое. Вы действительно хотите пройти через все это снова? - person onedaywhen; 16.12.2009
comment
Если вы программируете в Access, DAO является подходящим интерфейсом данных. Это так же верно для A2007, как и для всех предыдущих версий Access. У ADO есть несколько вещей, которые DAO не может делать, и их можно использовать с поздним связыванием и / или с помощью объекта CurrentConnection. Но DAO является подходящей библиотекой интерфейса данных для программирования в Access, где есть перекрытие с ADO (что составляет около 99%). - person David-W-Fenton; 17.12.2009
comment
Опять же, в вопросе нет ничего, что могло бы предположить, что контекст - это что-то иное, кроме ядра СУБД Access. Во-вторых, вы используете слово «подходящий» субъективно, т. Е. Предвзято относитесь к вашим личным предпочтениям. Все советы, которые я видел от Microsoft и Access Team, либо отдают предпочтение ADO, а не DAO, либо поддерживают их обоих в равной степени. В-третьих, перекрытие намного меньше 99% (для ADO подумайте о наборе функций Jet 4.0 плюс фабричная / иерархическая / отключенная асинхронная выборка, пакетное обновление, сохраненные как XML наборы записей и т. Д.). Возможно, 99% функций, которыми пользуются 80% пользователей. - person onedaywhen; 17.12.2009