Solved Uses Random numbers to generate custom id

[arnelgp]

Private Sub SerialTextboxName_Change()
    Dim sValue As String
    sValue = Me.SerialTextboxName.Text & ""
    If sValue <> "" Then
        SELECT CASE True
        CASE Me.Permit_Type Like "Bus*"
            Me.FleetTextboxname ="MOT/" & Me.RoutNo & "/" & sValue
        CASE Me.Permit_Type Like "Tricy*"
            Me.FleetTextboxname ="MOT/" & Me.Provice & "/" & sValue
        CASE Else
            Me.FleetTextboxname = "MOT/" & _
                Me.permit_type.Column(1) & "/" & sValue
        END SELECT
    Else
        Me.FleetTextboxname = Null
    End If
End Sub

 

[Gasman]

Why is nobody talking to me...
Have committed a crime?
Have violated the forum rules and regulations?
Have I insulted anybody?
Is it a crime that I learned step 1 and then try to achieve step 2 on my own using step1?
Can't somebody try to push for further answers using the one he learnt?
@theDBguy , @The_Doc_Man , @Gasman why are u people letting me suffer like this when i seek for solutions of my problems from you?

I AM SORRY IF MY MANNER OF APPROACH WAS WRONG but I need help on this please...
I promise I'll never trouble this site again if I am helped this last time


God Bless us all

I did not reply anymore, partly due to misleading us I admit, but mainly as arnelgp was responding to you, and he can do a far better job than I can.
Stay here. It looks like you will need the help, but be upfront as to what needs to be done or the target is.

I am all for breaking a problem down into small parts, but not when one takes you off in a direction that is not going to work for future problems. Waste of time exploring that direction.?

Good luck with your project.

 

[Nonnylizing]

Private Sub SerialTextboxName_Change()
    Dim sValue As String
    sValue = Me.SerialTextboxName.Text & ""
    If sValue <> "" Then
        SELECT CASE True
        CASE Me.Permit_Type Like "Bus*"
            Me.FleetTextboxname ="MOT/" & Me.RoutNo & "/" & sValue
        CASE Me.Permit_Type Like "Tricy*"
            Me.FleetTextboxname ="MOT/" & Me.Provice & "/" & sValue
        CASE Else
            Me.FleetTextboxname = "MOT/" & _
                Me.permit_type.Column(1) & "/" & sValue
        END SELECT
    Else
        Me.FleetTextboxname = Null
    End If
End Sub

Thank you and God's blessings

 

[The_Doc_Man]

We don't mind questions, and please don't stay away from the site. However, your approach is beginning to reveal a deeper problem. Your "piecemeal" modification to the requirements causes us to re-invent the wheel every time we answer you. What you did wrong was to not reveal the eventual goal and that is forcing us to drag your goals out piecemeal. You might not realize it but you are "hoarding" data that WE would need to help you solve your problem. The problem is one thing, but the approach that doesn't "lay all the cards on the table" makes you unusually high-maintenance. And you know what? That's OK, too, but it is time to discuss your data architecture at least in the abstract.

A further factor for slow response is that some of us, even when not in this time of corona virus crisis, have other factors to consider outside of the forum. At least that was true in my case because I had to install a new appliance when the old one died so I was up to my elbows in packing material and electrical hookups for a couple of days. Can't speak for the activities of others, but remember that all of us are volunteers and all of us have lives away from computer screens. Gasman made it clear that your approach was off and you've frustrated him by that approach. He'll get over it, he's a nice guy - but human like the rest of us.

So let's stop RIGHT HERE and ask the question. What do you intend to do LONG-TERM with that MOT/xxx/yyyy field that you are trying to build?

If all these modifications are for the eventual purpose of using it as a formal key in a table (key in the sense of table index), the correct answer is NO, don't do that. You will NEVER get this to work reasonably. You will only frustrate yourself - and us - with continual changes when something new comes along.

On the other hand, if it is a visual short-hand that will only appear in that complex format on forms and reports, then my earlier advice only needs to be slightly modified. If it is merely data for reports and is not being used as a multi-table key, those fields can appear in the table as separate entities that are appropriately combined on reports and on forms, which are the two main ways to look at table content.

Tell us your end-game. OR you could tell us that you don't know your end-game because you have not thought that far ahead because you are building this as you go. But think of it this way... if you go to a doctor and say, "Doc, I feel sick." ... and then stop right there, you are going to get short advice like "Take two aspirin and call me in the morning" but if your problem wasn't a headache, it won't do any good. Do you see why some of us have dropped out of your thread?