A family of Microsoft relational database management systems designed for ease of use.
You mean that it is better to do not use the autonumber and depend on a number which can be reused but not duplicate.
That's not exactly what I mean. It depends on what your autonumber field would be used for. Autonumbers are great for generating unique identifiers that will be used internally to link related records. In those cases, it doesn't matter what the number value is, and no one cares if the numbers are consecutive or have gaps in the sequence, so long as you have a unique key for each record.
Where autonumbers can cause problems are cases where they will be exposed to users, and the users will have expectations about them. For example, auditors tend to get upset with gaps in a sequence of invoice numbers, or even worse, check or deposit numbers. They want to know what happened to the "missing" transactions.
Some people say that you should never expose autonumbers to users under any circumstances. That doesn't mean you don't use them; it just means you use them only internally, and don't show them to the users. If the users need an ID number, you generate one over whose value you have more control, and for which you can ensure that there are no gaps in the number sequence. For that, you can use techniques like the one Ken Sheridan demonstrates in the database he linked to.
I will say that I don't completely hold with the rule to *never* expose an autonumber to the user. I haven't had a problem using an autonumber for an external ID in an application where I wouldn't expect any normal user to associate any sequence with the ID values -- identifiers for abstract entities that correspond to nothing concrete or "countable" in the real world. But for invoice numbers and things like that, autonumbers are right out.