Snippets and Thoughts of One Oracle Developer

S So I just published two Claude Code plsql-formatter and sql-formatter skills. The first one handles packages, procedures, functions, and triggers. The second handles the SQL side: standalone queries, any SQL embedded inside PL/SQL and views. Together they cover everything that lands in a real project. I split them into two skills because that is how Claude routes, by intent. Two skills, two trigger sets, no token waste on rules that don't apply. The Problem SQL Developer's built-in formatter is configurable, but every developer has a slightly different preferences and not everything can be customized there as you want. The result on a shared repo is a diff full of whitespace noise, columns realigned three different ways, WHERE clauses re-indented on every commit. So you spend time in code review fixing formatting instead of logic. Eventually you settle with a style which you don't really like. A skill fixes this differently. Instead of running a tool that rewrit...

I I live in Obsidian . My whole second brain sits in a git-versioned vault, and I open it every single day – for notes, work tasks, personal tasks, blog drafts, projects, everything. So if I'm staring at the same editor for hours, it might as well look the way I want. That's how I ended up building my own theme: One Oracle Developer . Catchy name, huh? It's a fork of the excellent Baseline theme, with a few tweaks on top. Why fork Create a theme from scratch is extremely demanding and time consuming. I checked all themes in Obsidian, and 95% of them were total garbage. Baseline was almost perfect, but I had to make a few small tweaks here and there so it works better with lists, checklists, and tags. I also adjusted the headers and fonts. The biggest issue was the folders/files tree, which felt a bit dull. Install Baseline and my theme and compare them yourself. What's different The theme is opinionated but small. Here's what it changes: Serif h...

F Four years ago I wrote Sharpen the saw . Same message still holds, but the saw changed. If you are still sharpening only what you know, you are sharpening the wrong thing. So let's do the uncomfortable check again. When did you last build something with AI (and I am not talking about few ChatGPT prompts)? When did you last try a new model, a new tool, or a new workflow? How much time did you spend last week consuming AI content vs. actually using AI to change something? Snowball with AI, or get buried by it Your knowledge is the small snowball. AI is the snow around. Used right, you compound years of experience into weeks of output. Used wrong, you generate plausible looking nonsense and call it a day. The point is not to let AI do your job. The point is to let AI do the boring 80% so you can go deeper on the part that actually needs you. Talking to users. Delivering value. If you are a senior and you still hand-write boilerplate code in 2026, you are burning ...

C Claude is great at many things, but it does not know your tools. It knows Oracle, it knows APEX, it knows PL/SQL. But it does not know ADT. So when you ask it to create a patch, it will hallucinate the commands and you will waste time fixing them. That is where skills come in. That is why I created ADT skills for you. What are skills? Skills are basically text files (SKILL.md) which you put in your project's ".claude/skills/" folder. When you ask Claude to do something, it reads these files first and follows the instructions. Think of it as a cheat sheet for Claude. You write the rules once and Claude will follow them every time. You can write skills for anything. Coding standards, naming conventions, deployment procedures, formatting rules. If you can describe it, Claude can follow it. I created two skills for ADT so far: adt and adt-setup . They are available on my AI_SKILLS repo . You can copy them to your project and adjust them to your needs. The ADT...

F A few years back, I created a view generator with support for JOINs. Unfortunately, it did not work for many use cases. It was bothering me for a while, so I decided to fix it. You list several tables with your preferred aliases, and it will find foreign keys between the tables (both ways) and apply them to the previous tables. So the table order is critical. I tried to adjust the table order based on the constraints, but that proved to be a bit challenging, so at least for now you have to figure out the table order yourself. Also, if you have columns with the same name, the later ones will be commented out. DECLARE in_tables CONSTANT VARCHAR2(4000) := ' TABLE_NAME1 t1, TABLE_NAME2 t2, TABLE_NAME3 t3, '; in_ignore_cols CONSTANT VARCHAR2(4000) := 'CREATED_BY,CREATED_AT,UPDATED_BY,UPDATED_AT,'; -- v_tables VAR...

A At times, I need to manage a long list of options; therefore, the logical approach is to organize them into groups rather than having everything in a single list. However, this approach introduces several challenges. Previously I just added another LOV item just with groups, but with multiple items you will quickly clutter your UI. The groups are sorted alphabetically. So if you want a different order, you have to use this neat trick, which add spaces at the start of your group name, and hence it gets sorted as you wish: SELECT NVL(g.group_name, INITCAP(g.group_code)) AS group_name, -- LPAD(' ', ROW_NUMBER() OVER ( -- reverse r# for proper grouping sets sorting hack ORDER BY g.order# DESC NULLS FIRST, g.group_code DESC ), ' ') || NVL(g.group_name, INITCAP(g.group_code)) AS group_name__, -- groups sorted, use in LOV as group -- ROW_NUMBER() OVER ( ORDER BY ...

A Any developer who has created a RESTful data service in APEX has faced the following issue: you create a service, and it does not work. It is a pain to debug REST services . This is typical of most APEX examples out there. You write your query or copy and paste your code here and there, and then move on. Low code, right? Never mind that it cannot perform proper code validation. Never mind that it cannot detect broken components in the future. As you might know from my previous blueprint articles or presentations, you should encapsulate everything in packages and views. That way, you can properly control your code and make sure your app continues to work. RESTful data services In short, REST services allow you to expose your data (basically SELECT statements) or logic (DML operations or more complex code) to other apps or systems. And it does not have to be a third-party system—you can consume your own services even from the same app. On the service side, you have to de...

A As a continuation of the first article , today I will focus mainly on APEX-related checks. To avoid one huge email, this part covers APEX-related checks, which you can find in the SEND_APPS procedure . Let's get started. I usually ignore all working copies, but even with this approach you might still have some leftover apps in your environment. So, in the CORE_CUSTOM package (under g_apps), you can limit the scope of your apps. This might be interesting: how would you select the same specific apps in multiple queries (without hardcoding the values in more than one place)? You declare the list in the package specification and create a function so you can use it in any statement: g_apps apex_t_varchar2 := apex_t_varchar2( 100, 110, 120, ... ); FUNCTION get_apps RETURN apex_t_varchar2 AS BEGIN RETURN core_custom.g_apps; END; Then you can use it like this: SELECT t.* FROM apex_applications t JOIN TABLE ...

I It sucks. You work your ass off for 10–20 years, you might have been a top performer, you bring many ideas to the company, you devote your free time to your project and team, and one day, they just let you go. Many employees seek an employment contract because of this false sense of security. I got a few opportunities to work for Oracle in the past, but after reading the contract, I had to say no. At least the contract in my country was ridiculous. Companies don't share the same ethics as you. They don't share the same values as you. They are not your family. Do you think your company owes you anything? You got your paycheck, didn't you? Anything else specified in your contract? Companies are built for profit, and large companies have to restructure from time to time to get leaner, remain competitive, and ramp up profits. As a shareholder, you would probably like this. As a top-performing employee being kicked out after 10 years of service, probably not so much. ...

I I'm using Git and the APEX Deployment Tool , so I very rarely lose code because I effortlessly export any changes and commit them right away. Mostly, I'm on the other side, breaking the code of others, those who still live in the stone age and keep everything only in the database. A friend of mine, Rafal , wrote about a great tool called Loki based on APEX. It might be a bit heavy, and I also have some customers who really don't want an APEX app to manage object locking. So here is mine lightweight implementation. All you need is: schema level DDL trigger CORE_LOCKSMITH table CORE_LOCKS to manage the locks small CORE_LOCK package to not have code in the trigger and for the extra actions (like extending or releasing the locks) Simple process you want to edit package, so you open it and compile it (right away, not after you work on it for half day) this will trigger the DDL event which will be catched by our AFTER DDL schema level trigger ...

O One of the most underrated things is checking the state of your database and APEX apps. You deploy things to Prod, nothing crashes (so far), so you move on. This is a strategy I've seen on many projects: no unit tests, barely some random user tests, and that's it. On top of that, in some projects I don't even have access to UAT. I only have access to Dev, but I somehow still have to make things work, even without read-only access anywhere else. So, how would you check things in a place where you don't have any access? Fortunately, I can at least send emails. So today, it's about the first email. What to check? The backend side contains mostly things for developers, like errors, logs, and security issues, or just to see what changed or what is different. Each link will take you to the source code of the appropriate view (because views are awesome: they keep the package readable and your reports flexible, since you can add your own views or remove the ones...

I If, for whatever reason, you decide you don't want the identity columns anymore and want to switch back to the classic sequences, this is for you. Here is the plan for how you can achieve it: get identity columns (identify tables and identity sequences) create new sequences for every table with "{TABLE_NAME}_ID" name get maximum value for each column to use it as a start value for new sequence create backup for objects source code replacements (in annotations) remove identity from all columns add new sequences as a default values fix source code (triggers, packages...); this is solved just partially To identify columns with identities: SELECT s.sequence_name, c.table_name, c.column_name, a.annotation_value AS old_seq_backup FROM user_sequences s LEFT JOIN user_tab_cols c ON c.data_default_vc LIKE '"' || USER || '"."' || s.sequence_name || '".nextval' LEFT JOIN user_annotat...

M Most of the projects I've worked on have this in common: "Release 1.0" as a version number. Only some projects have incremented this number, while keeping the same format. I don't like these artificial numbers, their informative value is close to zero. What I prefer instead is using the date and time of the last change. That can be easily automated, and you instantly know from which date and time the app is. For example, instead of "Release 1.0" you would have "2025-08-13 1.10.27", which consists of the date (YYYY-MM-DD) and time (HH24:MI), with "1." in the middle to make it look less like a time and more like an old-school version number. So, the app with the version number "2025-07-02 1.8.4" was changed on July 2nd at 08:04. Clear? As a developer, you can simply run a script when creating your patch, or even after deploying the app to the target environment, or schedule it to run as a job every hour or so. Since the...