Let’s get a virtual show of hands…how many of you have mastered the art of manually gathering a student’s home address? It works fine, right? That is, until you have students that don’t have that particular address type. How about calculating a person’s age? That one’s a little easier, but still has its quirks. Alright, one more: How many of you have tried your hand at manually calculating a student’s GPA and total credit hours? That’s one that will haunt you in your sleep. Fear not—I have a remedy for those sleepless nights. It’s Banner to the rescue!

It turns out that there are a bunch of handy little functions that come built-in with your Banner implementation. They’re all hiding under the BANINST1 schema, the same schema that houses all of those object access views that so many of you love. These functions are used by Banner in many different places – forms, procedures, and yes, even those object access views. I have found in my travels that many database administrators keep these functions hidden away for security purposes, so you might need to talk to that person to see if they will give you access to use them in your Argos queries.

These functions don’t actually change any data in the Banner database. They simply give easier access to the information, or give you a way to easily calculate certain metrics without turning into an insomniac. In addition to making your code cleaner and easier to read, these functions may also be updated when there are Banner upgrades. So in the case that a table gets some significant updates, the functions against that table will also be updated. You will not need to go into every one of your queries and make changes to adjust for those changed fields.

Each function does something different, so it is very important to know what the purpose of the function is, what parameters (or variables) it requires to run, and what it actually passes back for output. In some cases, the function will return just a single value result. In others, it returns a string of delimited values that need to be broken up into smaller bits. And finally, some simply return a ‘ROWID’, which is the Oracle pointer to the location of the matching record in the database. The best way to learn what these functions do would be to look at the code, either using a database tool, such as SQL Developer or Toad, or by sitting with a DBA or an IT staff person who can show you what each of them does.

For reference, we’ve put together a brief rundown of some more popular functions we use in Solutions Development, along with the Ellucian-provided comments found within the function. Take a look:

Of course, the functions on that list are just the tip of the iceberg. There are many, many more functions in BANINST1 that could potentially make your queries much cleaner and easier to code. You may also find a function that is close to what you want, but missing a few key pieces of information or special processing specific to your institution. In those cases, you may want to create your own local functions that use existing Banner functions as a starting point. You can even create a whole new custom function of your own, from scratch. By creating local functions, you can extend the usefulness of your Banner implementation, without actually changing the Banner code. Remember, the creation of custom functions may be limited to your institution’s programming staff, so be prepared to provide them with as much information as possible so they can create the function of your dreams!

If you are using functions (standard or custom) that you think we should all hear about, please share it in the comments below! We love to hear how our customers are using our products to do some nifty tricks!