Snippets and Thoughts of One Oracle Developer

E Exporting APEX should be done often if you are APEX developer. The more often you do it, the better position you will have. I export APEX every morning to see what other team mates changes (and forgot to commit). I also export it after each change. I modify the page, I export it. With this approach you need to export it fast. This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure Recompile invalid objects Searching APEX and searching repo for objects Export APEX & live upload (this article) Export database objects and data Patching & deployment Export APEX The full export is not always suitable. At least exporting just full export is something not version control friendly. And exporting just the pages is also not a great idea. That is usually done manually by teams who put everything on page, which goes against the Blueprint . You should not have logic (and queries) hardcoded on page

D Did you ever wondered which database objects are used in your application, in the whole application or just on a specific page? Or to find out where is the specific database object used? Or to find out at which commit was you database object dropped (or created, changed)? This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure Recompile invalid objects Searching APEX and searching repo for objects (this article) Export APEX & live upload Export database objects and data Patching & deployment Searching APEX The solution for searching APEX is based on parsing the Embedded code report export. So when you have this in your repo (and this is part of the next article on export_apex action), the searching is also faster then searching in APEX, it is also more accurate and the result list is much shorter, because it show just list of objects and pages as a table without all the clutter around.

I Invalid objects are often overlooked. Some teams don't care on DEV, others don't care even on PROD. Why would you care, if all you need to do is to wait for a first user who would crunch through the errors and that would recompile the invalid objects, right? It is not that hard to make sure everything is valid... This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure Recompile invalid objects (this article) Searching APEX and searching repo for objects Export APEX & live upload Export database objects and data Patching & deployment If you are looking for a PL/SQL solution, checkout the recompile procedure , which is part of the CORE project . ADT comes with improved script which can be part of your CI/CD pipeline. cd ~/Documents/YOUR_PROJECT_REPO/; adt recompile It recompiles invalid objects, but also the valid ones if you need to change PL/SQL flags. You can also limit

T The most complicated part about ADT is the installation. But don't worry, it is not that complicated and everything after that is super easy. This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure (this article) Recompile invalid objects Searching APEX and searching repo for objects Export APEX & live upload Export database objects and data Patching & deployment Install There is an Install guide in the repo, but in this article I will cover it in more details. You will need Python with some modules, SQLcl, possibly also Instant Client and Git. Here are the steps: clone ADT repo (lets say you clone it here: ~/Documents/ADT/) install any Git client, go for GitHub Desktop if you are new to this install Python 3.11 (and NOT 3.12 or higher) install SQLcl 24.1 install Instant Client 19.16 - required for thick connections (also you might need Java too), you can skip t

I Imagine this: You create a new page in APEX, or change existing one. Create new LOV, create a view for this LOV, create a view for report/grid on page, create a package to handle the logic... Now what? Now you have to get this to version control and you have to deploy it to other environments. So you want it now on test env, but you have to create a patch in a way, which can be run later on prod. With ADT you can do all of this without any effort just in few seconds. The whole idea behind ADT is to move as quickly as possible with minimum hassle for developers, to create something simple to setup, simple to explain, simple to use, so you can quickly start using it. Something which would save you a lot of time every day. This will be split to several articles: Introduction & workflow (this article) Setup connections, config, folder structure Recompile invalid objects Searching APEX and searching repo for objects Export APEX & live upload Export databas

I I like to use tabs. They are neat. They allows you to have multiple regions on page without cluttering page. They can also replace headers, if you have just one region in each tab. But sometimes I would like to have dynamic tabs (not just the names, also the number of tabs), so here is one method how to achieve that: Steps needed: create page item with Type = Radio Group at Settings set number of columns to whatever you need and Page Action to "Redirect and Set Value" (or create DA if you don't want the page refresh) at List of Values properties specify your source for the tabs at Appearance and Template Options pick "Display as Pill Button" at Item Group Display at Appearance add "TABS" as CSS Classes add CSS styles (below) to style these buttons as tabs And here is the CSS for Redwood: /* STYLE RADIO BUTTONS AS TABS */ .TABS .t-Form-labelContainer { display : none; } .TABS .apex-item-grid-row { di