This is a follow-up to a previous question I had (thank you for your assistance, @bordway).
However, I am running into another issue with that same BPM. Here is the scenario:
- User opens Job Entry
- User types in a Job Number
- Pre-Processing BPM Triggers on JobEntry.ValidateJobNum
That BPM will flow 1 of 2 ways:
- If JobNum ends in “-LC”, the BPM throws an exception and tells the user to try again, clearing the JobNum field in the process.
- If the JobNum does NOT end in “-LC”, the BPM does nothing and the user is free to continue on.
Now this works great if the user is entering a new job number, however the BPM is also triggering for existing jobs that end in “-LC”, which is problematic if someone is going to try and change one of those jobs.
Is there a way to have the VaidateJobNum BPM only trigger if it is a new Job Number, and not an existing one? Am I using the wrong method for this perhaps?
try “The Specified field of the changed row is equal to the specified expresion”
let it trigger, then within the BPM, do a lookup to see if the job exists in the jobhead table. If it does, then it is not a new record. If it does not, then it is a new record.
I am not sure that this method call has a changed row. I think it is a special method that passes parameters (not sure).
I think you could add a check for added record to your condition. Like this:
I thought about that, but there are no temp tables for the ValidateJobNum method.
Hmmm… I wonder if you grab the parameter - ipJobNum
store ipJobNum in a BpmData field and then do you condition check on that?
I am already looking at ipJobNum (which is how I know it ends in “-LC”), but I am unaware of a way for me to query the DB in a BPM to see if that JobNum is pre-existing or not.
That’s how you can query the DB
Just search for the JobNum in JobHead
I haven’t actually tried it myself, no idea if it would actually work.
I was thinking, off the top of my head that something like the query condition below?
THAT is what I was missing! Thank you!
Out of curiosity, is there a reason you’re using JobHead.ValidateJobNum instead of doing a pre-processing directive on JobHead.Update, with a top condition simply: If the ttJobHead.JobNum field of the Added row…?
If you do it on validate, it tells you right when you type it in, instead of when you try to save. It’s a better UI experience. But you are right, that update would work, and is an easier BPM to write. Also, it’s common to do both since update is a better gatekeeper for security type stops just in case something manages to slip through.