I need to be able to create a unique ID# which uses the date, selected in a textbox. And when there is more than one record with that month/year I need it to count the number of records with that month and year and create an ID incremented by one. So if there are 4 cases for the month of October 2013, I need it to create the id's as follows:
- CEF-1013-1
- CEF-1013-2
- CEF-1013-3
- CEF-1013-4
If have the following code:
Private Sub Text0_AfterUpdate()
'Creates a custom case number based on date and how many have been entered in that month/year
Dim caseNum As String
Dim caseCount As Integer
caseNum = Format(Forms!frmEnterCase!Text0, "mmyy")
caseCount = DCount("CaseID", "case", Format(Table!Case!CaseID, "mmyy") = caseNum)
caseNum = "CEF-" & caseNum & "-" & (caseCount + 1)
Forms!frmEnterCase!Text31 = caseNum
End Sub
For what it's worth, I would recommend that you keep the sequence number you derive in a separate numeric field, something like this:
That way you can streamline the process to derive new sequence numbers, and you can easily build the "CaseID" string from its constituent parts. (That is, it's always easier to glue strings together than it is to split them apart.)
The following test code illustrates how you could derive the sequence number when you insert the record into the table. Because the derivation is done inside the INSERT statement it should be done within an implicit transaction and therefore be suitable for a multi-user environment
The
Debug.Print
statement simply prints the SQL command to be executed, in this case......and the record is inserted into the table as follows:
If you want to display the CaseID then you can always piece it together "on the fly", like this...
...returning
...or, since you are using Access 2010 (or later) you could alter the [Cases] table to create a [CaseID] as a Calculated field using the expression
so you could just retrieve [CaseID] directly and wouldn't keep having to re-create the logic to assemble the CaseID every time you wanted to use it in a query or report.
You should be able to do something like this:
Note that I didn't test the code. It might need some tweaking/debugging. The basic concept still stands.
It's best to make functions for fetching/creating ID's in scenarios like this.
Also, I might mention that I would normally assign a meaningless Autonumber field as the Primary Key for a table like this, and then possible still use a meaningful CaseCode field similar to what you're doing here. Numeric Primary Keys perform better. While you do see it a lot, it's often considered a bad design practice to use meaningful Primary Key fields.