views:

251

answers:

2

Is there a way to use my own number in a table like an auto-number; that is to automatically assign the next available to a new record. We have system ID numbers for each employee that I want to tie into this database. I just want the table to auto assign the next number.

Can I do this? Could this be done with a mixture of numeric and alpha? Could criteria be used, like Code A = certain set of numbers, Code B = another?

Thanks!

+2  A: 

Of course you can, but you will have to design this yourself.

There are hundreds of ways of doing this but on way might be that you may have a parameters table with "nextQuote", "nextEmployeeNo", "nextJob"... of course your table design could have anything, including prefix example;

PARAMETERS
Prefix    Number
Q          1145
E            54
J           999

So now you can SELECT PreFix + MAX(Number) AS NextEmployee FROM Parameters WHERE Prefix = E

And in your code you can increment the number after dealing with it.

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

If this isn't up to the job then hopefully it will get you thinking in how you can do something similar.

Hope this helps.

Pace
yeah i think this will get me in the right direction. Thanks!
Justin
+1  A: 

For ADO users:

How To Implement Multiuser Custom Counters in Jet 4.0

For DAO users:

How To Implement Multi-user Custom Counters in DAO 3.5

onedaywhen
wow thanks a lot! this is what i was looking for!
Justin
Unfortunate that the article you cite uses ADO and JRO, two technologies that one really shouldn't need when working with Jet/ACE data stores. This article shows how to do the same thing in DAO: http://support.microsoft.com/kb/191253/EN-US/ -- it does not require any additional references or late binding and is 100% equivalent to the ADO/JRO version (i.e., it does exactly the same thing with the Jet db engine).
David-W-Fenton
I'll refrain from editing and let my comment stand, simply because to re-edit it to be appropriately worded, I'd eliminate the full content of your post and replace it with mine, since the ADO version is pretty much irrelevant in an Access context.
David-W-Fenton
First, there nothing in the question to suggest the context is anything other than the Access Database Engine. Second, "technologies that one really shouldn't need" and "the ADO version is pretty much irrelevant" are merely argumentative: ADO vs DAO and all that. Do you really want to go through all that *again*?
onedaywhen
If you're programming in Access, DAO is the appropriate data interface. That is as true in A2007 as it has been in all previous versions of Access. ADO has a few things that DAO can't do, and can be used with late binding and/or using the CurrentConnection object. But DAO is the appropriate data interface library for programming in Access where there is an overlap with ADO (which is about 99%).
David-W-Fenton
Again, there nothing in the question to suggest the context is anything other than the Access Database Engine. Second, your use of word 'appropriate' is subjective i.e. biased towards your own personal preferences. All the advice I've seen from Microsoft and the Access Team either favours ADO over DAO or favours them both equally. Third, the overlap is much less than 99% (for ADO think the Jet 4.0 feature set plus fabrciated/hierarchical/disconnected asychronous-fetching, batch-updating, saved-as-XML recordsets etc). 99% of the features that 80% of users use, perhaps.
onedaywhen