Skip to main content

Posts

Showing posts with the label sql

Different SYSDATE behaviors in SQL and PL/SQL

The SYSDATE function is available in both SQL and PL/SQL. They both return the current date-time (down to nearest second) for the database, So it would be reasonable to assume that they "act" the same in both SQL statements and PL/SQL blocks. That would, however, be a bad assumption to make, because in reality: In SQL, SYSDATE is called just once for the entire statement. In PL/SQL, SYSDATE is called every time it is invoked. Wow. Mind blown.  Let's take a look. In the script below, I create a table and insert four rows. Then I create a package that keeps track of distinct dates added to a collection and show those dates. Finally, a function that uses the package. CREATE TABLE tab (id INT) / BEGIN INSERT INTO tab VALUES (1); INSERT INTO tab VALUES (2); INSERT INTO tab VALUES (3); INSERT INTO tab VALUES (4); COMMIT; END; / CREATE OR REPLACE PACKAGE tracker AUTHID DEFINER IS TYPE when_t IS TABLE OF INTEGER INDEX BY VARCHAR2 (100); dates when_t;...

An Application Alerting Utility

A few weeks ago, Mike Hichwa asked me to come up with a package that would implement a simple alerting utility: specify a triggering event (based on a query or a PL/SQL expression) and then take the specified actions when it is triggered. Seeing as he is my boss, I said "OK" and got to work (my favorite kind of work: writing some PL/SQL code). We did our usual bit to expand scope, then did our usual bit to agree that this is enough for a first pass. And then Mike said: "Go ahead and write a blog post about it, share it with the community." So here goes. The basic idea is we start up a job using DBMS_SCHEDULER that runs every N minutes. When it runs, it checks to see if any alerts need to be triggered. If so, it then takes one or more actions associated with that alert. Let's start with our tables. Utility configuration How often should the job wake up? Should it disable checking for alerts? What is the name of the "callout" for sending ema...

Comparison Methods for Object Types

There are special member methods -  map  or  order  methods - that we use to tell Oracle Database how to compare two objects of the same datatype. This capability is critical when we want to perform an equality test in PL/SQL or when sorting objects in SQL. There is no default way to do this. In other words, if I create a simple object type, add it as a column to a table, and try to compare or sort, all I get are errors. Let's take a look. First I will create a table that has an object type as a column and add a couple of rows. CREATE TYPE food_ot AS OBJECT ( name VARCHAR2 (100), food_group VARCHAR2 (50), grown_in VARCHAR2 (100) ) NOT FINAL / CREATE TABLE meals ( served_on DATE, main_course food_ot ); / BEGIN INSERT INTO meals (served_on, main_course) VALUES (SYSDATE, food_ot ('Shrimp cocktail', 'PROTEIN', 'Ocean')); INSERT INTO meals (served_on, main_course) VALUES (SYSDATE + 1, food_ot ('House Salad...

Using Object Types in Relational Tables

So far in my series on object-oriented development in Oracle Database, all manipulation of object type instances have taken place in PL/SQL. But as you may have guessed from the fact that you "CREATE OR REPLACE" object types, those types are also available for us in SQL. You can create relational tables of object types, called object tables. You can also define columns of relational tables whose datatypes are object types. In this post, I will explore both of these approaches. All the code you see below may be found in this  LiveSQL script , so you can get to know these features by playing around with them yourself. Object Tables It's easy to create object tables and work with the instances in those tables (both selecting and changing rows of data). Here's a simple example: CREATE TYPE food_ot AS OBJECT ( name VARCHAR2 (100), food_group VARCHAR2 (50), grown_in VARCHAR2 (100) ) NOT FINAL / CREATE TABLE food_table OF food_ot (CONSTRAINT food_ta...

Using Always Free Autonomous Database to help me heal our planet

So I signed up for my Always Free Autonomous Database (AFAD) and a boatload of other cloud services. OK, what shall I do with them? Hmmm....well....as some of you may know, I've gotten very concerned about climate change and human-caused extinctions. I started a project with Vincent Morneau called fabe - for all a beautiful earth - to help all of us reduce consumption, rescue species and reconnect to nature. Check it out at https://fab.earth . Yes, it is an APEX application and it is already running on an Oracle Database cloud service, so....what else? You know the saying "think globally, act locally"? Well, if fabe is global, then my work on invasive species is local, very  local. When I lived in Chicago, I went out to the nearest "wild" spaces I could find and cut back buckthorn trees that didn't belong in Chicago, out-competed native trees for sunlight, and killed off those native species. I rescued trees  - and the literally millions of living...

Always Free Autonomous Oracle Database: Let's get going!

On September 16, Larry Ellison announced a new Always Free tier for Oracle Cloud, which (for me) most importantly includes an Always Free Autonomous Oracle Database. For nothing but the "cost" of providing your credit card information (which is only used for identification purposes and is henceforth ignored until you decide to upgrade to a paid service), everyone in the world now can use the most powerful, most advanced database in the world FOR FREE. Of course, there are limits. But oh my what generous limits they are! Get lots more details here . And it's not just the amazing Autonomous Database (in both transaction processing and data warehouse flavors). You get Oracle Application Express (APEX) so you can build websites  writing very little code, and taking full advantage of your SQL and PL/SQL skills. You get SQL Developer to write what code you need and manage your database. You get Oracle Rest Data Services to build REST endpoints against your...

Object Types and Object-Oriented Development with PL/SQL: the Series

Find below the list of my blog posts in a series on working with object types (a.k.a, classes) in Oracle Database and, specifically, PL/SQL. This series is not intended to offer an in-depth training on object-oriented development; instead, it introduces basic O-O concepts and shows how they are implemented in Oracle Database with PL/SQL. Introduction to Object Types, Part 1 Object Types and Inheritance, Part 2 Object Types Methods, Part 3 Using Object Types in Relational Tables, Part 4 Comparison Methods for Object Types, Part 5 Dynamic Polymorphism - Why, What, How, Part 6 Each post also contains a link to a LiveSQL script, so you can try out all the code yourself.

Working with Object Type Methods

Packages have subprograms (procedures and functions). Object types have methods. Object type methods are, still, procedures and functions. But there are also different types and characteristics of methods that only make sense in an object type, which supports inheritance and dynamic polymorphism. In this post, 3rd in my series on object types, I explore Static methods  Member methods  Non-instantiable methods  Invoking methods of super types All the code you see below can be run in Oracle LiveSQL through this script . Member Methods Member methods are methods applied to an instance of the type. Almost all the methods you ever write for an object type will be a member method. Assuming you are already familiar with writing PL/SQL functions and procedures, the most important thing to come up to speed on is the SELF value. Member methods have a built-in (implicit) parameter named SELF that denotes the object instance currently invoking the method. We'll...

The Ten Commandments of PL/SQL Development

A long, long time ago in a blog long ago lost to the shrouds and clouds of memory, I published a Ten Commandments of PL/SQL Development. A Twitter follower recently asked me for them, and lo and behold actually found them lurking in a Word doc on my drive. So I have decided to share them with you, largely unchanged. In some places I have struck through entirely irrelevant or outdated text, and also offered updates for 2019. 1. Thou shalt encapsulate your SQL statements behind procedure and function calls. Sure, it's really, really easy to write SQL in your PL/SQL programs -- in fact, it's way too easy. SQL is the "Achilles' heel" of your application code. You code and you code and you code, and before you know it, you have dozens of variations of the same SQL statement making their negative performance impact known in your application. You can't analyze the impact of data structure changes and you find enhancements to be very expensive. Solution? Put all ...