Events – Validate Basics

Part TWO!

I’ve decided to split part two into two parts (maybe part 3 will be split in thirds).  First, a general discussion of validation events, pros, cons and things you should know.  I’ll follow up in another week (or two, or three – my record here isn’t great) with some additional samples of checks and automation done via validation events.

First, the basics.  A validation event fires whenever you modify an object and then hit ‘apply’, ‘ok’, or navigate off the object you’re modifying.  Pretty straightforward.  So, when would we use a validation event?  I see two potential uses for them (please let me know if you’ve got any others).

1. As a real-time substitute for a custom check.  Why wait for someone to request a model check if you can validate it as soon as the object has changed and let them know on the spot.
2. As a way to automate a common task by performing a repetitive action when an object is modified.

This is very appealing but does have a few potential problems.  Why wait for someone to hit the check model (or rely on them actually doing it) if you can ensure they’ll hit the same validation as soon as they make the mistake?  Why let the modeler potentially make the same error 200 times on a model before they bother to run a check and discover they’ve made the same error over and over again?  If you let them know immediately, they’ll learn to do it right immediately.

Well, it turns out there is a downside.  First, validation events allow you to raise an error, and potentially correct it (similar to auto-correct on an event) but makes it much harder to produce a nice concise list of errors.  In addition, if your event forces something to be fixed, the modeler may get annoyed if you’re enforcing rigor they might not be ready for yet.  For example, if they’re trying to lay down a quick model during a working session, being forced to enter a comment on every column could get in the way.  You could have the event write a warning to the output window without forcing the user to correct the issue but that’s easy to overlook and you’ll still need a custom check.  Second, you only get one validation event on each object class.  That can lead to a LOT of code in one big chunk if you’re trying to do multiple checks.  You can split it out into subroutines but there could still be an awful lot going on.  The last problem, related to the second is that there can be a fair amount of overhead involved.  You could be firing a lot more events than you think you are.

For demonstration purposes, I’m going to modify the XEM file I started for initialize events and walk through a little example.  We’ll create two events and see what happens.

First, let’s open our XEM file and edit the global script.  I’m going to add these lines:

dim eventCounter
eventCounter = 0

We’ll use event counter to track how many times we fire a validation event when we test.  Now we’ll create a couple of events.  First, we’ll create a column level validation event.  Here’s the code:

Function %Validate%(obj, ByRef message)

   eventCounter = eventCounter + 1

   output eventCounter & ":  Column Level Event Handler on " & obj.Name

   %Validate% = True
End Function

Next we’ll create a table level validation event

Function %Validate%(obj, ByRef message)

   eventCounter = eventCounter + 1

   output eventCounter & ":  Table Level Event Handler on " & obj.Name

   %Validate% = True

End Function

Before we go ahead and test, there’s one more topic we have to cover.  In the general options for the tool, there’s an option called “Auto Commit”.  Having autocommit on basically pushes the apply button after every change.  I typically have autocommit on, because I’m lazy and don’t make mistakes (at work… people have pointed out plenty on this blog…  you should take my word on this instead of asking my co-workers).

Here’s where the options is.

Now, let’s create a table and see what happens in the output window.  I’ve extended the XEM file I used for the initialization event demo.  This will create a set of audit columns on ever table automatically.  Notice that when we create two columns via script, the event doesn’t fire.

I’ll create a table with the audit columns and add two more on.  I’ll do it once with autocommit enabled and once with it off, resetting the counter in between.

Here’s the results.

Autocommit On:

1:  Table Level Event Handler on Table_1
2:  Column Level Event Handler on Column_3
3:  Table Level Event Handler on Table_1
4:  Table Level Event Handler on Table_1
5:  Table Level Event Handler on Table_1
6:  Table Level Event Handler on Table_1
7:  Table Level Event Handler on Table_1
8:  Table Level Event Handler on Table_1
9:  Column Level Event Handler on Column_4
10:  Table Level Event Handler on Table_1
11:  Table Level Event Handler on Table_1
12:  Table Level Event Handler on Table_1
13:  Table Level Event Handler on Table_1
14:  Table Level Event Handler on Table_1
15:  Table Level Event Handler on Table_1
16:  Table Level Event Handler on Table_1
17:  Table Level Event Handler on Table_1
18:  Table Level Event Handler on Table_1
19:  Table Level Event Handler on Table_1
20:  Table Level Event Handler on Table_1
21:  Table Level Event Handler on Table_1
22:  Table Level Event Handler on Table_1
23:  Table Level Event Handler on Table_1
24:  Table Level Event Handler on Table_1
25:  Table Level Event Handler on Table_1
26:  Table Level Event Handler on Table_1
27:  Table Level Event Handler on Table_1

Autocommit Off:

1:  Table Level Event Handler on Table_2
2:  Column Level Event Handler on Column_3
3:  Column Level Event Handler on Column_4

So, with autocommit on, we get 27 events with autocommit on.  With autocommit off, we get 3.  The model I’m working with has two tables table with 4 columns each.  The validation events are only writing messages to the output window.  If your validation events are complex and you have a lot of functions, you can start incurring a lot of overhead.  If you add validation events to a lot of metaclasses, you could impact performance.  The takeaway –

1. don’t overuse validation events
2. autocommit OFF – if you’re going to use validation events, make sure your modelers know that autocommit may be a problem.
3. write code that will not cause problems if it executes multiple times if you’re going to insist on leaving autocommit enabled (see rule #2).

I’d stick with validation events for items that are difficult to correct after that fact and you’re concerned that people will make repeatedly if they aren’t made aware of the issue immediately.  If your point is to let people know there’s a problem early and “teach” them what they’ve done wrong, you might also consider having the event notify the user of the error along with corrective actions without actually “fixing” the problem.

That’s enough of the basics.  Check back in a week or so for more on validation events.