Dr. Sarath Kumar S

  If you've worked long enough on enterprise applications, you know that production issues are not a matter of if but when. No matter how carefully we design, develop, and test, there will always be situations where something behaves differently in production than it did in development. Over the years, I've been part of enough production support calls to realize that some PL/SQL practices have saved me repeatedly. Interestingly, none of them are particularly advanced. They're simple habits that I developed through experience, usually after learning a lesson the hard way. One of the most valuable practices has been avoiding hardcoded values. Early in my career, I occasionally used hardcoded IDs, statuses, or business conditions because they seemed unlikely to change. Of course, they eventually did. A small business change would suddenly require code modifications in multiple places. Now, whenever possible, I store configurable values in tables and reference them through code...

  One thing that has stayed constant throughout my Oracle development journey is my reliance on PL/SQL packages. Looking back, I don't think I fully appreciated their value when I started. Like many developers, I was focused on delivering features quickly. If a requirement came in, I'd write a procedure, test it, and move on to the next task. The application worked, and that felt like success. As projects grew, I started noticing a pattern. Small changes were taking longer than they should. A business rule that seemed straightforward to update would somehow exist in multiple places. Fixing one issue sometimes created another because the same logic had been implemented differently across modules. I found myself spending more time searching for code than actually writing it. That was when I started taking PL/SQL packages seriously. Instead of creating standalone procedures for everything, I began grouping related functionality together. Employee operations lived in one package, a...

  When I started working with Oracle APEX, I assumed that building applications was mostly about creating pages, writing SQL queries, and adding a few processes. After working on enterprise applications involving approvals, reporting, integrations, document generation, and workflow automation, I realized that successful Oracle APEX development is less about knowing every feature and more about understanding how to design applications that remain maintainable over time. Looking back, there are several lessons I wish someone had shared with me earlier. These lessons would have saved me countless hours of debugging, redesigning, and maintaining applications. 1. Spend More Time Designing the Database When I first started developing applications, I focused heavily on the user interface. The reality is that a well-designed database solves many problems before they reach the application layer. Poor table structures eventually lead to: Complex SQL queries Slow reports Difficult maintenance...

  Generating reports is a common requirement in enterprise applications. Generating dynamic train seating charts, however, is a completely different challenge. Recently, I worked on a project that required producing detailed train seating charts in Microsoft Word format. At first glance, the requirement sounded straightforward: display train cars, seats, and passenger information. The reality was much more complex. The seating arrangement depended on train configuration, travel direction, car sequence, occupancy status, and passenger assignments. Additionally, the final output needed to be generated as a professionally formatted document that could be distributed to operational teams. This is where Oracle APEX and APEX Office Print (AOP) proved to be an excellent combination. Understanding the Requirement The business team wanted a report that would show: Train details Car information Seat assignments Passenger details Direction-specific layouts Printable output in Word format The ...

  Email notifications are often one of those application features that nobody thinks about until something goes wrong. For years, many Oracle applications relied on custom PL/SQL packages, database mail configurations, and complex procedures to generate and send emails. While these solutions worked, they often became difficult to maintain as applications evolved. Recently, I worked on a project where several legacy email procedures needed to be modernized. The application contained thousands of lines of PL/SQL dedicated to constructing email bodies, identifying recipients, handling exceptions, and managing attachments. The objective was simple: migrate the existing email functionality to Oracle APEX's built-in email framework without changing the business process. What appeared to be a straightforward migration turned into a valuable learning experience. Understanding the Existing Logic The first challenge was understanding how the current implementation actually worked. Like many ...

  When an Oracle APEX application starts behaving unpredictably, developers often look at page processes, JavaScript, session state, or SQL performance. However, one issue that frequently goes unnoticed is the improper use of temporary tables. I recently reviewed an application where users were reporting missing records, inconsistent dashboard counts, and approval screens that sometimes displayed data and sometimes did not. At first glance, everything looked normal. The queries were correct, the pages loaded successfully, and no obvious errors appeared in the logs. The root cause turned out to be a temporary table that was being used as the primary source for application data. What seemed like a simple design choice eventually became one of the biggest reliability issues in the application. Why Developers Use Temporary Tables Temporary tables are attractive because they provide a quick way to store intermediate data. Developers often use them to: Store report results Stage data bef...

  One of the most common complaints I hear from business users is surprisingly simple: "The dashboard looks good, but I still have to export everything to Excel." As developers, we often focus on building visually appealing dashboards with charts, cards, and metrics. However, users rarely judge a dashboard by how attractive it looks. They judge it by how quickly it helps them find answers and make decisions. Over the past few years, I have worked on multiple Oracle APEX applications for operations teams, finance users, approval workflows, and reporting systems. One lesson became clear very quickly: users do not want more dashboards. They want dashboards that solve problems. The Mistake Most Dashboard Projects Make Many enterprise dashboards start with a list of requirements that includes: Pie charts Bar charts KPI cards Interactive reports Export options The result is often a screen filled with information but very little insight. Users open the dashboard once, become overwhe...

  In many organizations, approval processes start simple but gradually become complicated as business requirements evolve. What begins as a straightforward manager approval workflow often turns into a series of emails, spreadsheets, manual follow-ups, and approval bottlenecks. Recently, I worked on a project where users were spending a significant amount of time managing approval requests manually. The process involved tracking approvals through email chains, identifying pending approvers, following up on delayed actions, and manually updating records after decisions were made. The objective was clear: reduce manual effort, improve visibility, and create a centralized approval process. Understanding the Existing Process Before implementing any solution, I spent time understanding how approvals were being handled. The existing workflow had several challenges: Approvers received requests through email. Users had no centralized view of pending approvals. Delegation during employee abs...

  When I started building enterprise applications in Oracle APEX, I believed that writing working code was enough. If the page loaded, the report displayed data, and users could complete their tasks, I considered the project successful. After working on multiple enterprise applications involving approvals, integrations, reporting, emails, and thousands of records, I realized that developing enterprise systems requires a completely different mindset. Many of the problems I faced were not caused by Oracle APEX itself. They were caused by design decisions that seemed reasonable at the time but created challenges later. Looking back, here are five mistakes that taught me some valuable lessons. Mistake 1: Focusing on the Current Requirement Instead of Future Changes Early in my career, I built applications exactly as requested. If the business asked for one approval level, I created one approval level. If they wanted a specific report, I built that report. The application worked perfect...

  There are projects where you simply add a few enhancements and move on. Then there are projects that force you to question every design decision that was made before you arrived. Recently, I worked on an approval workflow in Oracle APEX that belonged to the second category. What started as a small enhancement request quickly turned into a complete rebuild of the workflow. Looking back, it was one of the most rewarding Oracle APEX projects I have worked on. The Problem The original approval process had been running for quite some time. Users could submit requests, approvers could review them, and notifications were sent at various stages. On paper, everything looked fine. However, when we started investigating issues reported by business users, several problems became obvious: Workflow data was stored in temporary tables. Approval routing logic was spread across multiple pages and processes. Delegation management was difficult to maintain. Approval history was incomplete. Dashboar...