My preferred tool for writing PL/SQL code has been DataGrip from JetBrains for the last few years. Working on a case with reference partitioned tables, I came over some strange errors. At first I thought Oracle had a lot of bugs in the partitioning syntax, but it turned out to be DataGrip messing with my DDL!
Read More »Proxy user logon #JoelKallmanDay
Are you using proxy logon when connecting to your Oracle database? Why not?
Read More »Generating data: union all vs insert all
To test out different physical table lay-outs, I had to repeatedly generate some test-data. After a few runs, I wanted to speed it up a bit. This is how I did it.
A small unexpected to_date oddity
I was about to do some date/time calculations as I got an unexpected result with the to_date-function.
Read More »
Yet another reason to unit test your (PL/SQL) code
The last few months, I’ve had the pleasure of using utPLSQL v3, a unit testing framework for PL/SQL, on a new project that I’m working on. Sure – writing tests takes a bit extra time, but it’s such a huge help when you’re constantly refactoring a system that grows from zero.
LOVs or Lists of values – one solution fits quite a few
Applications often have the need to have selection lists present and/or limit the possible choices for entry in a field. Some lists need to be static, and others need to be a bit more flexible in terms of adding new values. I’ve seen several solutions to this, and having been “stuck” on 11g for a long time, I thought I’d test out a “new” way of doing it using a composite foreign key and hidden columns.
Debug domino
We found a bug in some old code. And we fixed it. Then other stuff started failing. It turned out that there were some other code, using the same function, that worked because of the bug. That forced us to roll back the fix and thereby re-introduce the initial bug that weren’t as critical.
So – we had to find a way to find out which code-paths were working because of the bug so we could fix those.
Reviewing statements with hints, using PL/Scope
In my previous post, I showed how you can add a fake hint to tag the origin of a duplicated statement and as a side-effect make it unique. What if you regret and can’t remember where it was. Or you want to review old hinted statements after an upgrade to a newer version of the database/optimizer.
Differentiating between duplicated statements
Finding duplicate SQL statements using PL/Scope is easy. If you cannot merge them, how can you differentiate between which source is being run?
Find bad performing queries or code with PL/Scope
On our production system we’ve enabled the collection of PL/Scope metadata. Since this is a SmartDB/PinkDB-application (business logic and queries in the database), this makes it really easy to find, inspect and modify the source code of queries that doesn’t run efficiently. Now it’s even easier using reports in Oracle SQL Developer.
- nice theory... 