Based on a 2026 Oracle APEX Budapest Meetup talk

This article is based on material I presented at the Oracle APEX Budapest Meetup on June 10, 2026, during a session about Oracle APEX 26.1 and AI-assisted development.

The focus here is APEXlang: why I believe it represents more than a new export format, and why it may become an important bridge between Oracle APEX, source control, AI-assisted development and enterprise governance.

For years, Oracle APEX has given developers a higher level of abstraction.

We do not normally build every page by writing low-level code.

Instead, we describe what we want:

• a report
• a form
• a validation
• a process
• a navigation entry
• an authorization rule

APEX turns those declarations into a working application.

That declarative model is one of the reasons APEX can be so productive.

But AI-assisted development introduces a new question:

How can an AI understand an APEX application well enough to help us build and modify it safely?

This is where I find APEXlang particularly interesting.

APEXlang is not just another export format

At first glance, APEXlang can look like a different way to export an APEX application.

I think that interpretation is too narrow.

The more important idea is that the application becomes available as a readable, structured application specification.

In other words:

Business intent
      ↓
APEXlang specification
      ↓
Review and governance
      ↓
Running APEX application

That changes how we can think about an APEX application as a development artifact.

Traditionally, an export was often something we mainly associated with:

• deployment
• migration
• backup
• source control

APEXlang adds another possibility:

the application definition itself becomes something humans, development tools and AI assistants can reason about.

An Open Application Specification Language

The way I described APEXlang in my presentation was:

an Open Application Specification Language for Oracle APEX.

The important word here is not only language.

It is specification.

APEXlang describes the application at a higher level.

It focuses on the application's structure and intent rather than trying to represent everything as low-level implementation code.

That makes it naturally compatible with the declarative philosophy APEX has always had.

APEXlang is designed to be:

• declarative
• human-readable
• AI-friendly
• file-based
• versionable
• mergeable
• suitable for review
• compatible with modern development workflows

This is an important distinction.

The goal is not:

Generate as much code as possible.

The goal is:

Express the application clearly enough that people and tools can understand what it is supposed to do.

From black box to readable source

Low-code platforms have always had an interesting challenge.

They give us abstraction and productivity.

But that abstraction can also make the application definition harder to inspect outside the development environment.

A traditional export may be technically useful while still being difficult to:

• read
• compare
• review
• validate
• explain to an AI model

APEXlang addresses this visibility gap.

Conceptually:

Traditional application export

harder to read
harder to diff
harder to review
harder for AI to interpret

              ↓

APEXlang

readable
versionable
diffable
reviewable
validatable
AI-friendly

That matters even without AI.

But AI makes the value much easier to see.

A simple APEXlang example

An application specification can describe things such as:

page "Sales" {
    id: 5

    identification {
        name: Sales
        title: Sales
    }

    security {
        authentication: pageRequiresAuthentication
    }

    regions {
        region "Sales Dashboard" {
            identification {
                name: Sales Dashboard
                type: classicReport
            }

            source {
                location: localDatabase
                type: sqlQuery
            }
        }
    }
}

Even without knowing every detail of the syntax, a developer can understand what is being described.

There is:

• a page
• a title
• an authentication requirement
• a report region
• a database source

This is very different from asking an AI assistant to infer the structure of the application from screenshots or an opaque deployment artifact.

The AI needs application context

When AI assistants work well with source code, one reason is simple:

they can see the source.

They can analyze:

• files
• functions
• dependencies
• structures
• changes

Historically, that has been more difficult with low-code applications.

The application may be perfectly understandable inside the low-code IDE, while an external AI tool has very little useful context.

APEXlang helps close this gap.

Instead of giving the AI screenshots and saying:

Guess how this application works.

we can give it a structured application definition.

That creates much better conditions for AI-assisted development.

This is not "vibe coding for APEX"

One of the messages I emphasized in the meetup was that APEXlang should not be interpreted as uncontrolled AI code generation.

The workflow I find more interesting looks like this:

Prompt
   ↓
APEXlang
structured application definition
   ↓
Review
Git diff + rules + validation
   ↓
Import
   ↓
APEX application

The roles are different:

AI
↓
accelerates

APEXlang
↓
makes the intent visible

Developer
↓
controls

That is a much better enterprise development model than:

Prompt
↓
Generate something
↓
Hope it works

The intermediate specification matters.

Why the intermediate representation matters

A prompt is temporary.

A specification can become a durable development artifact.

Suppose I tell an AI:

Create a customer search page.

That prompt alone is not enough for a serious business application.

We still need to know:

• which data source it uses
• which fields are searchable
• which users are allowed to access it
• how navigation works
• which components belong to the page
• what validations apply
• how the result fits the rest of the application

In an enterprise environment, we need something persistent between the idea and the running application.

Conceptually:

"Create a customer search page"
                ↓
             APEXlang
                ↓
     structured specification
                ↓
              review
                ↓
       controlled application

This is where I see APEXlang becoming much more than an export mechanism.

AI speed with enterprise control

Generative AI is very good at increasing speed.

Enterprise software development needs something else as well:

control.

We need to be able to answer questions such as:

• What changed?
• Who reviewed the change?
• Is the application still secure?
• Can we reproduce the application?
• Can we compare two versions?
• Can we validate the result?
• Can we audit the development process?

AI generation does not remove these requirements.

If anything, faster generation makes them more important.

The faster we can create software, the more important it becomes to understand what has actually been created.

Source control becomes more meaningful

A file-based, readable representation naturally fits source control better.

A possible workflow becomes:

APEX application
      ↓
APEXlang export
      ↓
Git
      ↓
change
      ↓
diff
      ↓
review
      ↓
merge
      ↓
import

Now consider AI inside the same process.

Requirement
      ↓
AI-assisted generation
      ↓
APEXlang change
      ↓
Git diff
      ↓
Developer review
      ↓
Validation
      ↓
APEX

This is a very different development model from letting an AI modify production application behavior without a visible intermediate step.

The developer stays in control

One of the most important points for me is that APEXlang does not make the APEX developer irrelevant.

I believe the opposite is more likely.

AI can generate.

APEXlang can make that generation visible.

But someone still needs to understand:

• the business requirement
• the APEX model
• Oracle Database
• security
• architecture
• performance
• maintainability

That remains the developer's responsibility.

I summarized the roles like this:

AI
accelerates

APEXlang
makes the application intent visible

Developer
understands, evaluates and controls

The developer's job does not become:

Write every component manually.

But it also does not become:

Type a prompt and accept whatever appears.

The role moves toward:

• understanding intent
• evaluating generated specifications
• correcting them
• approving them
• validating architecture
• protecting security and maintainability

From implementation to application intent

This is a broader change in how I think about AI-assisted development.

The most important artifact may increasingly become the application intent.

Traditionally we often move from requirement to implementation like this:

Requirement
    ↓
Developer interpretation
    ↓
Implementation

With generative tools, another model becomes possible:

Requirement
    ↓
Structured application intent
    ↓
AI + developer
    ↓
Implementation

APEXlang gives that structured intent a possible technical form.

That is why I find the philosophy behind it more interesting than the syntax itself.

A generative APEX development lifecycle

The development lifecycle I presented can be summarized like this:

Requirements
business intent
      ↓
AI Generation
prompts + agents
      ↓
APEXlang
      ↓
Source control
merge + diff
      ↓
Application Builder
      ↓
Application
      ↓
Runtime

But the flow is not necessarily strictly linear.

Developers may work directly in Application Builder.

AI tools may generate or modify application specifications.

Source control may contain the shared definition.

The important point is that these paths can converge around a common application artifact.

That creates a new balance between:

business intent → AI → developer tools → review → running application

APEX was already prepared for this idea

What makes this particularly interesting is that APEX has always been declarative.

The platform already works at a higher level of abstraction.

We do not normally say:

Generate the HTML, JavaScript, server logic and database interaction for this complete report manually.

We say:

This is a report.

The platform knows how to implement it.

That is one reason I think APEX and generative AI fit together naturally.

AI is much more useful when it can operate on concepts that have clear meaning.

For example:

page
region
report
form
item
validation
process
authorization
navigation

These are already part of the APEX vocabulary.

APEXlang makes that vocabulary available in a form external tools can work with.

The "what", not only the "how"

One of the design goals I find particularly important is abstraction.

APEXlang aims to describe what the application should contain rather than forcing developers to express everything in terms of how the platform internally implements it.

This mirrors the strength of low-code itself.

A low-code platform gives developers leverage because they work with higher-level concepts.

AI can potentially benefit from the same abstraction.

Instead of generating large amounts of low-level code, the AI can work with application concepts.

That is a much more attractive direction for maintainable enterprise software.

Human-readable matters

It is tempting to think that if AI generates the application, humans do not need to understand the generated representation.

I strongly disagree.

Human readability becomes even more important when generation becomes faster.

If a generated specification is readable, the developer can ask:

• Is this really what we wanted?
• Is this page correct?
• Is authentication required?
• Did a new region appear unexpectedly?
• Did the SQL source change?
• Has a security rule disappeared?

Human readability makes AI output reviewable.

Without reviewability, enterprise adoption becomes much harder.

Diffable matters

Imagine asking an AI:

Add a new filter to the customer search page.

I do not only want the result.

I want to see the change.

customer search page

+ item "Country"
+ source: CUSTOMER.COUNTRY_ID
+ lov: COUNTRY_LOV

The exact syntax is less important than the principle.

A developer should be able to review what changed before accepting it.

This is one of the reasons source-control-friendly application definitions are important.

Mergeable matters

Team development also requires merging changes.

One developer may work on one part of the application.

Another developer may work on another.

An AI assistant may propose a third change.

If the application definition can participate in normal source-control workflows, these changes become much easier to manage systematically.

This brings low-code development closer to development practices that are already familiar in code-centric environments.

Validation matters

AI can produce incorrect output.

This is not unique to AI.

Developers produce incorrect output too.

The difference is speed.

AI may produce a large amount of incorrect output very quickly.

That makes validation essential.

A structured specification creates opportunities for automated checks before a change becomes a running application.

The principle is:

Generate
   ↓
Validate
   ↓
Review
   ↓
Deploy

not:

Generate
   ↓
Deploy immediately

Governance matters

For enterprise applications, governance is not optional.

We need standards.

For example:

• naming conventions
• security requirements
• approved components
• architectural patterns
• logging requirements
• accessibility rules
• database standards

If application intent is represented in a structured way, it becomes easier to imagine automated governance around it.

An organization could potentially verify that generated application changes comply with its internal rules before they are accepted.

That is much more interesting than AI generation alone.

AI-assisted development is broader than generation

At the June 2026 meetup, the broader theme was AI-assisted development in Oracle APEX.

Generation is only one part of that.

AI may help developers with:

• understanding existing applications
• explaining PL/SQL
• generating initial structures
• suggesting changes
• documenting applications
• analyzing reports
• creating test ideas
• working with project knowledge

The important question is not:

Can AI generate an APEX application?

The more useful question is:

Where can AI remove repetitive work while keeping the application understandable and controlled?

APEXlang as context for AI assistants

One particularly useful role for APEXlang is context.

An AI assistant needs to understand the application before giving useful advice.

A readable application definition can give it that context.

A workflow could look like this:

APEX application
      ↓
APEXlang
      ↓
AI assistant
      ↓
"Explain this page"

"Where is this authorization used?"

"Which pages depend on this shared component?"

"Suggest how to add this requirement"

"What changed between these two versions?"

This may be just as valuable as generation.

In mature enterprise systems, understanding existing applications is often more important than creating new applications from scratch.

This connects to something I was already thinking about

In 2023, I was already asking what generative AI could mean for Oracle APEX application development.

At that time, one of the interesting possibilities was moving from natural-language requirements toward generated application structures.

I wrote about that evolution here:

Generative AI in Oracle APEX: From a 2023 Vision to APEX 26.1 →

APEXlang makes that discussion much more concrete.

The missing layer between:

natural language

and:

running application

can now become a structured application specification.

That is an important architectural difference.

Prompt engineering is not enough

Another reason I like this direction is that it moves the discussion beyond prompt engineering.

A good prompt is useful.

But enterprise application development needs more than a good prompt.

It needs:

Requirement
+
Application model
+
Data model
+
Security
+
Standards
+
Existing application context
+
Review

The prompt is only one input.

APEXlang can provide a more durable representation of the application itself.

The future APEX developer

I do not expect the APEX developer to disappear.

I expect the role to change.

Less time may be spent on some repetitive implementation tasks.

More time may be spent on:

• business analysis
• data modelling
• architecture
• security
• defining application intent
• reviewing AI output
• integration
• validation
• governance

That is not a weaker developer role.

It is a role operating at a higher level of abstraction.

The database still matters

It is also important not to separate this discussion from Oracle Database.

An APEX application is not only a collection of pages.

In serious business systems, much of the value is in:

• the data model
• SQL
• PL/SQL
• constraints
• security
• integrations
• transactional consistency

AI-assisted APEX development still depends on these foundations.

APEXlang can describe more of the application layer.

It does not remove the need to understand the database underneath it.

This is why my own professional journey still feels continuous:

Oracle Database
      ↓
Oracle APEX
      ↓
Oracle Cloud
      ↓
AI-assisted development

AI is not replacing the previous layers.

It is building on them.

What should APEX teams do now?

My recommendation at the meetup was not to try to transform everything at once.

Start with a small use case.

For example:

• explain an existing report
• analyze an APEX application definition
• generate documentation
• explain PL/SQL
• create a small application specification
• build an internal project assistant

Then measure the value.

Look for:

• time saved
• fewer errors
• faster onboarding
• less repetitive work
• better documentation

And build reusable patterns.

For example:

prompt templates
PL/SQL packages
REST wrappers
logging
authorization patterns
review processes

AI usage itself is becoming a development skill.

Developers need to learn:

• how to ask
• how to provide context
• how to verify
• how to recognize risk
• how to control the result

The real question is not how much AI can generate

AI can generate more and more.

That is becoming less surprising every year.

For enterprise development, I think the more important questions are:

Can we clearly express what the application should do?

Can we inspect what the AI created?

Can we compare it with the previous version?

Can we validate it?

Can we review it?

Can we govern it?

Can we maintain it five years later?

That is why I believe APEXlang is important.

Looking back from 2026

When I look at APEXlang, I do not mainly see a new file format.

I see the continuation of the original APEX philosophy.

APEX has always allowed us to describe applications at a higher level than traditional hand-coded development.

APEXlang takes that declarative model and makes it more visible to:

• developers
• source control
• development tools
• automation
• AI assistants

That visibility may become extremely important in AI-assisted software development.

The idea in one sentence

If I had to summarize the philosophy in one sentence:

APEXlang connects the speed of AI with the declarative model of Oracle APEX and the control required by enterprise software development.

The future question may not be:

How much code can AI generate?

It may be:

How clearly can we express, validate and govern application intent?

That is the direction I find much more interesting.

Based on a 2025 Oracle APEX Budapest Meetup talk

This article is based on my presentation “Generative AI with Your Own Data and Documents”, delivered at the Oracle APEX Budapest Meetup on November 26, 2025.

The article follows the ideas, architecture and practical experiments I presented at the time, adapted into English for publication on davidpataki.com in 2026.

Generative AI becomes much more interesting for a company when it can work with information that actually belongs to that company.

A general-purpose language model can already do many impressive things.

But businesses usually want more.

They want AI to understand:

• their own data
• their own documents
• their own terminology
• their own rules
• and their own business context

That was the topic I explored in late 2025:

How can we use generative AI with our own enterprise data and documents?

What do companies actually want from generative AI?

For a business, the goal is not simply to have access to a large language model.

The goal is to create value from it.

In my presentation, I summarized three main objectives:

• create value from language models
• simplify processes and improve operational efficiency
• operate virtual assistants that can improve employee productivity

These goals sound straightforward.

The implementation is not.

The enterprise challenges

There were several challenges I wanted to understand through practical experiments.

Too many models

The AI market was already moving very quickly.

Different models had different capabilities, behaviors and limitations.

Choosing a model was therefore not necessarily a one-time architectural decision.

Company-specific knowledge

A general model does not automatically understand a company's internal information.

It does not know:

• internal processes
• project documentation
• business rules
• database structures
• private documents

The model needs access to the right context.

Infrastructure and authorization

Enterprise AI cannot simply receive unrestricted access to everything.

Infrastructure and permissions become part of the AI architecture.

Hungarian language

For us, this was especially important.

An enterprise AI solution used by Hungarian employees and customers also needs to perform well in Hungarian.

That is something I explicitly wanted to test rather than simply assume.

An LLM alone is not enough

One of the main messages of the presentation was:

the language model itself is not enough.

Consider three very different requests.

“How much were my weekly sales?”

The model needs access to company data.

Question
   ↓
Company data
   ↓
Answer

Without access to the actual sales information, the model cannot answer reliably.

“Turn off the lights at 9 PM.”

Now information retrieval is not enough.

The AI needs to perform an action.

Request
   ↓
API call
   ↓
External system

“Analyze the proposal based on my own policy.”

Here the model needs company-specific knowledge and instructions.

Proposal
   +
Company policy
   +
Instructions
   ↓
Reasoning

These examples represent three important enterprise AI requirements:

data, tools and business context.

Working with structured data: Select AI

One of the technologies I tested was Select AI.

The idea is especially interesting for Oracle-based applications because the question can be expressed in natural language while the relevant information already exists in Oracle Database.

In my test application, I experimented with multiple providers and compared the generated SQL.

For the same request, I could inspect SQL generated through different configurations.

The goal was not simply to create a chatbot.

The interesting part was connecting natural-language interaction to existing enterprise data.

DBMS_CLOUD_AI.GENERATE

The presentation also included direct use of DBMS_CLOUD_AI.GENERATE.

A simplified example from the demo was:

DBMS_CLOUD_AI.GENERATE(
    prompt       => v_prompt,
    profile_name => 'OPEN_AI',
    action       => 'showsql'
);

The profile determines the AI configuration used for the request.

The environment I presented supported several provider options, including:

openai
cohere
azure
database
oci
google
anthropic
huggingface
aws

The available actions included:

runsql
showsql
explainsql
narrate
chat

This gives us different ways of using a language model around database information.

For example, sometimes I only want to see the SQL.

In another situation I may want to execute it, explain it or generate a natural-language response.

Credentials and profiles

The configuration separates several concerns.

Conceptually:

Credential
     ↓
AI Profile
     ↓
DBMS_CLOUD_AI.GENERATE
     ↓
Provider

This is useful because the application does not have to hard-code everything about the model into each AI request.

The profile becomes an important part of the configuration.

Voice can be another input

The presentation also contained an experiment where spoken input became part of the process.

The flow was approximately:

Voice
  ↓
WAV
  ↓
Base64
  ↓
Speech-to-Text
  ↓
Transcript
  ↓
AI processing

The transcript could then become the prompt passed to the AI service.

This was another example of an important idea:

the AI interface does not have to begin with typing into a chat box.

Business users may interact through different forms of input.

From Select AI to an AI agent

The next step in my experiments was an AI agent.

The difference is important.

Instead of using only one model call, the agent can work with several tools.

In the architecture I presented, the agent had access to different types of capabilities:

Agent
  ↓
Tools

Those tools could include:

RAG
SQL
Custom tool
Agent tool

This changes the role of the language model.

Instead of being expected to know everything itself, it can use the appropriate tool depending on the question.

RAG for company documents

For information stored in documents, I tested a RAG-based approach.

The structure presented at the meetup was:

Agent
  ↓
Tool
  ↓
RAG
  ↓
Knowledge Base
  ↓
Bucket
  ↓
File

The knowledge base could contain files such as:

PDF
DOC
PPT
images

Metadata was also part of this structure.

Conceptually:

File
  +
Metadata
  ↓
Knowledge Base

This makes it possible for the agent to work with information that is not stored as normal relational database rows.

Why documents matter

A large part of a company's knowledge is not stored in tables.

It may exist in:

• policies
• job descriptions
• presentations
• specifications
• internal documents
• other uploaded files

In one of my demonstrations, I asked the agent about employee experience levels based on job descriptions.

The important point was that the answer was expected to come from the available documents.

If the information could not be found there, the agent should not simply invent it.

That is very different from asking a general model to make a guess.

SQL as an agent tool

Documents are only one source of enterprise knowledge.

Another important source is the database.

The agent architecture therefore also contained a SQL tool.

The SQL tool could be configured with:

• schema configuration
• in-context learning examples
• descriptions of tables and columns
• custom instructions

Conceptually:

Agent
   ↓
SQL Tool
   ↓
Schema configuration
Table and column descriptions
Examples
Custom instructions
   ↓
Database

This gives the model additional information about how to interact with the database.

Why database descriptions matter

A human developer who knows an application already understands much of its database context.

The AI does not.

A column name alone may not explain its real business meaning.

That is why descriptions of:

• schemas
• tables
• columns

can be valuable.

The AI needs context about the data model before it can use that model effectively.

In-context learning examples

The presentation also included in-context learning examples as part of the SQL tool configuration.

Examples can help the model understand how particular questions relate to a company's database.

Rather than relying only on generic knowledge, we can provide patterns that are specific to our application.

This again reflects the central theme of the talk:

enterprise AI becomes useful when general model capabilities are combined with company-specific context.

Custom instructions

The SQL tool could also receive custom instructions.

These instructions help shape how the tool should behave within the company's environment.

This is another layer between a generic language model and a useful enterprise assistant.

The model provides the general language capability.

The configuration provides the business-specific guidance.

Other tools

The architecture was not limited to RAG and SQL.

I also included:

Custom tool
Agent tool

The purpose of the experiment was to see the AI agent as a coordinator of different capabilities rather than as a single isolated chatbot.

Conceptually:

                     ┌── RAG
                     │
User → Agent → Tools ├── SQL
                     │
                     ├── Custom tool
                     │
                     └── Agent tool

The agent can decide which capability is relevant to the user's request.

One question may need a document

For example:

What does our policy say about this situation?

The appropriate source may be the knowledge base.

Question
   ↓
Agent
   ↓
RAG
   ↓
Company documents

Another question may need database data

For example:

Who has tasks this week?

Now the answer belongs in structured business data.

Question
   ↓
Agent
   ↓
SQL tool
   ↓
Database

The user should not need to decide which technical mechanism is required.

That is the agent's job.

And another request may require an action

A more advanced request may eventually need a specialized tool or API.

Question / instruction
        ↓
Agent
        ↓
Custom tool
        ↓
External operation

This is why I found the agent model more interesting than simply putting a chat interface in front of an LLM.

What did I learn from the experiments?

At the end of the November 2025 presentation, I summarized my practical conclusions.

These were not theoretical conclusions.

They came from experimenting with the different approaches.

The SQL tool was not efficient enough

In the form I tested at the time, my conclusion was:

the SQL tool was not efficient enough.

That does not mean that using AI with SQL is a bad idea.

In fact, my Select AI experiments showed the opposite.

But the particular agent-tool approach still needed improvement.

RAG worked well

My experience with RAG was much more positive.

RAG worked well.

For questions based on company documents, this approach showed clear potential.

This was particularly important because documents contain a large amount of business knowledge that is difficult to use through traditional structured queries.

Select AI worked well in OCI

Another positive conclusion was:

Select AI worked well in OCI.

Natural-language access to database information was therefore one of the stronger parts of the experiment.

For an Oracle-based application environment, that was particularly relevant.

The cost was acceptable

Cost is always part of enterprise architecture.

An impressive demo is not useful if normal usage makes the solution economically unrealistic.

In my experiments, my conclusion was that:

the price was acceptable.

That made further experimentation worthwhile.

Hungarian required more testing

One of the open questions remained the Hungarian language.

My conclusion was that we needed:

more Hungarian-language tests for further tuning.

This matters because a solution that works well in English does not automatically provide the same experience in another language.

For a Hungarian business application, this cannot be ignored.

Tool tuning still needed work

Another point in the presentation was the usefulness of OpenAI in helping to tune the tools.

The tool definitions and instructions matter.

An agent is only as useful as the tools it can call and the way those tools are described.

This means that building an AI agent is not simply:

Connect model
→ done

It is an iterative process.

Efficient APIs matter

Another conclusion was the importance of efficient APIs.

If an AI agent is expected to perform business operations, the quality of the available tools becomes critical.

The AI layer cannot compensate indefinitely for poorly designed interfaces underneath it.

A good AI agent therefore also depends on good application architecture.

Some limitations remained

The original presentation explicitly identified several limitations.

I had listed three of them as points that still needed attention.

I will not reconstruct those details from memory here because the purpose of this article is to preserve what was actually demonstrated in 2025.

The important point is that the system was promising but not something I considered finished.

Language and vision were still open questions in Hungarian

Another conclusion from the tests was that Language and Vision in Hungarian were not yet where I wanted them to be.

Again, this is why practical testing matters.

A feature list can tell us what a service supports.

It cannot tell us whether the experience is good enough for our specific users and language.

What the experiment changed in my thinking

The most important lesson for me was that there is no single technology called “enterprise AI.”

A useful company assistant needs access to several different capabilities.

The architecture I explored looked more like this:

                         User
                           ↓
                         Agent
                           ↓
                         Tools
              ┌────────────┼────────────┐
              ↓            ↓            ↓
             RAG          SQL       Custom tools
              ↓            ↓            ↓
         Documents      Database       APIs

The language model sits above these capabilities.

It helps understand the user's request and work with the result.

But the actual company knowledge still comes from company systems.

The LLM is only one part of the solution

This brings us back to the point from the beginning:

the LLM is not enough.

If the user asks about sales, the AI needs data.

If the user asks about internal rules, it needs documents.

If the user wants something to happen, it needs a tool or API.

The model provides the conversational and reasoning layer.

The enterprise systems provide the real context.

Looking back from 2026

I presented these experiments on November 26, 2025.

What I find most useful about them today is that they moved the discussion away from the question:

Which AI model should we use?

and toward more practical questions:

What information does the AI need?

Where does that information live?

Is it structured data or a document?

Which tool should retrieve it?

Does the agent have enough context to use that tool correctly?

Can the solution work reliably in the language our users actually speak?

Those questions are still much more important to me than simply connecting another LLM.

The most promising architecture was not a chatbot with access to everything.

It was an agent with specific, controlled tools for different kinds of enterprise knowledge.

For our Oracle environment, that meant combining ideas such as:

Select AI + SQL + RAG + company documents + tools.

That was the real lesson of the experiment:

generative AI becomes useful for a company when it can work with the company's own context - through the right tool for the right information.

Based on a 2024 conference talk

This article is based on my presentation “Linking All My APEX Together with REST Enabled SQL”, delivered at APEX Alpe Adria on April 12, 2024.

It reflects the architecture, problems and lessons I presented at the time, adapted into article form for publication on davidpataki.com in 2026.

Running a software development company means constantly trying to answer questions that are surprisingly difficult to answer well.

What are my developers working on?

What should we be working on?

What have we already completed?

What do our clients want from us?

Are we within budget?

Is the project profitable?

And perhaps most importantly:

Do I actually have enough information to answer these questions in time?

In 2024, I presented at APEX Alpe Adria how we approached this problem at Enrol Consulting using Oracle APEX and REST Enabled SQL.

The technical solution was important.

But the real problem was information.

The information problem

At the time, there were several things I found difficult to follow:

• what my employees were doing

• what we should do next

• what we had already done

• what our clients wanted us to do

• whether we were within budget

• whether a project was profitable

• whether individual employees were profitable

• whether we had deviated from the project plan

• which errors still had to be handled

The information existed.

The problem was that it often arrived:

• too late

• in too little detail

• too generally

• too fragmented

This is a common problem in software projects.

The customer has information.

The developer has information.

The project manager has information.

The application has information.

The timesheet has information.

But these pieces do not necessarily form one coherent picture.

A typical workflow

A simplified software development workflow might look like this:

Customer
   ↓
Idea / need / error
   ↓
Task management
   ↓
Developer
   ↓
Doing / fixing
   ↓
Timesheet
   ↓
Testing

The problem becomes more complicated when the customer's business application and the development company's internal task-management system are separate.

A requirement may originate inside the client's application, while the corresponding task is managed somewhere else.

The developer then performs the work in the client's environment and later records it in yet another place.

Every additional system increases the chance that information will be:

• duplicated

• delayed

• simplified

• forgotten

• disconnected from its original context

What did we actually need?

We identified three important goals.

Manage tasks where they belong

A problem occurring on a particular page of an application should be easy to create and follow from that context.

The user should not have to leave the business application, open another task-management product and reconstruct where the problem occurred.

Manage all tasks in one place

From our side, however, we needed a consolidated view.

We work with multiple applications and multiple clients.

Project managers and developers cannot efficiently manage work if every client's requests remain isolated inside separate systems.

Make administration as easy as possible

This was especially important for developers.

If recording information creates too much additional work, people naturally postpone it.

And once information is entered days later, it becomes less accurate.

So the goal was not to create more administration.

The goal was to capture useful information as part of the work itself.

Two systems, one workflow

The basic architecture involved two different environments:

Client's ERP / APEX application
             ↕
      REST Enabled SQL
             ↕
        Enrol's ERP

The client continued using their own application.

We continued using our own internal ERP.

REST Enabled SQL connected the two.

This allowed the client-facing functionality to stay where it made sense while giving us a centralized view of the work.

The customer did not need to become a user of our internal project-management system.

And our developers did not need to manually recreate every customer request inside another application.

Why REST Enabled SQL?

Oracle APEX applications are frequently built around Oracle Database.

When both sides of an integration belong to the Oracle ecosystem, REST Enabled SQL provides an interesting option.

Instead of building a separate REST endpoint for every individual operation, an APEX application can work with SQL and PL/SQL executed against a REST-enabled remote Oracle schema.

For our use case, this was attractive because the data model and business processes were still evolving.

But REST Enabled SQL was not something we simply enabled and forgot about.

The original presentation deliberately included several questions we had to consider:

• limitations of REST Enabled SQL

• security

• the right architecture

• what happens when the connection is unavailable

• user synchronization

• maintainability

Those architectural questions were just as important as establishing the connection itself.

The connection schema

One of the important architectural decisions was the use of a separate connection schema.

Instead of exposing the internal ERP schema directly, the integration could operate through a dedicated database layer.

Conceptually:

Client APEX application
        ↓
REST Enabled SQL
        ↓
Connection schema
        ↓
Internal application data

This provided a natural place to control what the remote application could access.

The connection layer could expose only the database objects and operations required by the integration.

That separation matters.

When connecting systems, the easiest technical solution is not always the architecture you want to maintain for years.

Client-side configuration

The client application also needed its own REST Enabled SQL configuration.

Once the remote data source had been configured, APEX components could use information from the connected environment.

Some of the practical examples in the presentation included:

• Lists of Values

• lists of users

• lists of statuses

• application maintenance

• status maintenance

• user maintenance

This meant that information did not necessarily have to be duplicated into every client database.

The application could retrieve the relevant values through the connection.

Think about maintenance from the beginning

Connecting two systems is only the first step.

Sooner or later, something changes.

A new system is added.

A status changes.

A user joins or leaves.

Permissions change.

That is why the presentation included dedicated maintenance functions for:

Systems
Statuses
Users

These may look like small administrative details.

They are not.

An integration that works only while its original configuration remains unchanged becomes expensive very quickly.

The maintenance model is part of the architecture.

User synchronization is a real problem

Users are particularly interesting.

The same person may exist in both environments, but the two systems do not necessarily identify them in the same way.

A developer may exist in our ERP.

A customer user exists in the client's system.

Permissions and identities may change independently.

The original project therefore had to consider user synchronization as a separate architectural issue.

This is a good example of why integration is rarely just about transporting data.

You also need to decide what the data means on both sides.

What if there is no connection?

Another question we considered was simple:

What happens when the remote system cannot be reached?

Distributed systems fail.

Networks fail.

Services become temporarily unavailable.

Authentication can fail.

An architecture that assumes a permanent connection without considering failure conditions will eventually create problems.

This is especially important when the remote functionality is embedded inside the normal user workflow.

The technical integration should therefore never be considered separately from availability and error handling.

The resulting workflow

The final solution connected our internal ERP and the client's ERP through REST Enabled SQL.

The customer could work with development-related information from their own application.

For example, they could:

• add new client needs

• define priorities

• follow tasks

• ask additional questions

• answer questions

• report errors

At the same time, our internal system could use that information for:

• time management

• project planning

• an overview of all projects

The fundamental idea was:

Customer works here
        ↓
Client's application
        ↓
REST Enabled SQL
        ↓
Enrol's ERP
        ↓
Project management and development

The customer stays in the customer's application.

Our team stays in our system.

The information connects the two.

Everything happens in context

One of the most important design goals was that the customer should be able to work with the task where the task actually belongs.

Imagine that a user is on a particular page of an APEX application and finds a problem.

Instead of opening a completely separate task-management system, the application can already know:

• which system the user is in

• which page they are on

• which business context is involved

The request can therefore be connected to that context from the beginning.

This reduces one of the most common sources of wasted time in support and development:

“Which screen are you talking about?”

Task list

From the client's point of view, tasks can still appear as a normal part of their application.

They can see the tasks relevant to their system.

They do not need access to all projects or all customers.

On our side, those same tasks can become part of a consolidated task-management environment.

This gives the two sides different views of the same work.

Editing a task

A task is not just a text description.

During its lifecycle it accumulates information.

For example:

• description

• priority

• questions

• answers

• assignments

• status changes

• timing information

Connecting the task to the application gives all of this information context.

How many issues are related to this page?

One of the ideas demonstrated in the original presentation was showing the number of issues related to the current system or page.

This is a small feature, but it illustrates the advantage of integration very well.

Instead of thinking of task management as a completely separate application, task information becomes another dimension of the business application.

A user can see that there are open issues related to the area they are currently using.

That is very different from maintaining a completely disconnected ticket list.

A task is also a history

We did not only need the current status of a task.

The sequence of status changes was valuable too.

Conceptually:

Task
 ├── Status 1
 ├── Status 2
 ├── Status 3
 └── Current status

A task's status history tells a story.

It can show when:

• work started

• additional information was requested

• the customer responded

• development finished

• testing began

• a problem was reopened

• the task was completed

That history later becomes useful for reporting.

Tasks became part of a larger model

In our internal system, the task did not remain an isolated object.

It became connected to other business information.

The presentation showed relationships between areas such as:

Client
  ↓
System
  ↓
Order
  ↓
Task
  ↓
Task Status

Task
  ↓
Timesheet
  ↓
Developer

Developer
  ↓
Employee Performance

Orders and Tasks
  ↓
Financial Planning

Developer
  ↓
Presence Planning

Client
  ↓
Transaction
  ↓
Invoice

This is where the solution became much more valuable.

Once the task is connected to the rest of the company's operational data, it becomes possible to analyze much more than whether the task is open or closed.

From task management to time management

The next step was connecting tasks with timesheets.

Traditional timesheets often have an inherent problem.

At the end of the day—or sometimes several days later—the developer has to remember:

What exactly did I work on?

But our system already had activity information.

It knew which tasks the developer had interacted with.

That gave us the idea of showing:

Tasks I have touched today

Instead of starting from an empty timesheet, the developer could start from actual task activity.

A different approach to filling the timesheet

The process became approximately:

Tasks I touched today
        ↓
Assign hours
        ↓
Assign start time / break
        ↓
Generate the daily time settlement

This is a fundamentally different experience from entering timesheet rows from memory.

The administrative process starts with data that already exists.

The developer mainly needs to add the time dimension.

Daily time settlement

Once the tasks and hours are connected, the system can create a daily time settlement.

Now every recorded period of work has context.

It is not just:

8 hours - development

It can be associated with:

Developer
    ↓
Task
    ↓
System
    ↓
Project / Order
    ↓
Client

That produces much more useful management information without requiring the developer to enter all of that information manually.

Better data changes reporting

The final part of my 2024 presentation focused heavily on the results.

Once tasks, statuses, systems, projects, developers and timesheets were connected, we could build reports that previously would have been difficult or unreliable.

Project phases

Because task statuses were recorded over time, we could analyze project phases.

Instead of having only a current snapshot, we could see how work moved through the process.

This helps answer questions such as:

• Where is work accumulating?

• Where do tasks spend the most time?

• Has testing become a bottleneck?

• Are many tasks waiting for additional information?

Activity based on statuses

Status changes also became a useful measure of activity.

They do not tell the complete story of developer productivity.

But they provide another view of what is happening in the system.

The important thing is that this information is generated naturally by the workflow.

No separate reporting process is required just to create the data.

What are we working on now?

This was one of the questions that originally motivated the project.

With the integrated data model, we could begin answering it from actual system activity.

The answer no longer depended only on somebody manually preparing a project-status report.

Systems, projects and orders

Tasks could also be analyzed in the context of projects and orders.

That allowed us to compare planned work with actual activity.

For a software company, that connection is particularly important.

A project can appear busy while consuming much more effort than expected.

Without connecting task activity to commercial and planning information, that problem may only become visible much later.

Project timesheets

Because timesheet entries were connected to tasks and projects, project-level time analysis became much more accurate.

We could move from:

How many hours did this developer report?

toward questions like:

How much effort did this particular project, system or group of tasks consume?

That is much more useful for project management.

Task statuses over time

The presentation included reports analyzing task statuses over selected periods.

Historical status information can reveal patterns that a current task list cannot.

For example, a current task may simply show:

Done

But the history can reveal that it spent a long time waiting in another phase.

That information can help explain delays and improve future planning.

Tasks assigned to developers

Because tasks were connected to developers, workload distribution could also be analyzed.

Again, the purpose was not simply to count tasks.

Ten trivial tasks and one major task are not equivalent.

But task assignments combined with statuses, estimates and timesheets provide useful context.

Closed and open tasks

The system could analyze task statuses both including and excluding closed tasks.

This matters because different questions require different views.

For operational work, we may care mainly about active tasks.

For retrospective project analysis, closed tasks are essential.

A good reporting model needs both perspectives.

Overrun tasks

Once estimated effort and actual timesheet information exist in the same data model, we can identify tasks whose actual effort exceeds expectations.

Conceptually:

Estimated effort
       vs.
Actual recorded effort

This is one of the most useful connections between task management and financial management.

Without the connection, overruns may become visible only at project level.

With it, the problematic task can be identified much earlier.

Overdue tasks

The same applies to deadlines.

Open and closed tasks can be evaluated against expected completion dates.

That provides a practical basis for investigating:

• delays

• bottlenecks

• underestimated work

• blocked activities

System profitability

This was one of the questions at the very beginning of the presentation:

Is the project profitable?

By connecting clients, systems, orders, tasks, developers and timesheets, we created a much stronger foundation for answering that question.

The integration did not magically calculate profitability.

It did something more fundamental:

it created the data relationships required to understand it.

Weekly dashboard

The same data could finally be summarized in management dashboards.

The path from the original problem to the dashboard was not:

Build a better dashboard

It was:

Capture better information
        ↓
Connect it to the right business objects
        ↓
Make the workflow easy enough to use
        ↓
Then build the dashboard

That distinction is important.

A beautiful dashboard cannot fix incomplete or fragmented source data.

What I learned from the project

Looking back at the 2024 presentation, REST Enabled SQL was an important part of the solution.

But it was not the main lesson.

The main lesson was about information flow.

We wanted to manage tasks where they naturally belonged.

We wanted to see all development work in one place.

And we wanted the administrative burden to be as small as possible.

REST Enabled SQL helped us connect those goals technically.

The database was the integration layer

There is also a broader architectural lesson here.

Both sides were based on Oracle technologies.

That meant the database itself could play a significant role in the integration.

Rather than moving all data into a new central application or forcing every customer to use the same task-management interface, we could connect applications while allowing each system to retain its role.

For this particular use case, that was a very powerful model.

Would I use REST Enabled SQL everywhere?

No.

The presentation itself already considered:

• its limitations

• security

• architecture

• availability

• user synchronization

• maintenance

Those questions still matter.

For public integrations, external consumers or strongly versioned service contracts, a dedicated REST API may be a more appropriate abstraction.

But when connecting Oracle-based environments that we understand and control, REST Enabled SQL can be a remarkably productive tool.

The right question is not:

Is REST Enabled SQL better than REST APIs?

The better question is:

Which integration model best fits the systems, data ownership, security requirements and development process we actually have?

Looking back from 2026

I gave this presentation on April 12, 2024.

Two years later, I find the underlying idea even more relevant than the specific implementation.

Modern development gives us more tools, more APIs, more automation and increasingly more AI.

But the central architectural questions remain surprisingly stable:

• Where should the information live?

• Where should the user work?

• Who owns the data?

• How can we avoid entering the same information twice?

• How do we capture useful data without creating unnecessary administration?

• How do we turn operational activity into information that helps us make better decisions?

In our case, connecting multiple Oracle APEX applications with REST Enabled SQL was one practical answer.

The result was not simply an integration between databases.

It was a connection between:

customer needs, tasks, developer activity, time, project planning and business results.

Based on a 2023 talk

This article is based on a presentation I gave at the Oracle APEX Budapest Meetup in October 2023.

The examples used the familiar Oracle HR schema, but the underlying planning principles apply to much larger business applications as well.

Oracle APEX makes it very easy to start building.

That is one of its greatest strengths.

But it also creates a temptation:

to start creating pages before thinking through the application structure.

For small applications, this may work.

For larger business systems, it usually creates problems later:

• inconsistent navigation
• duplicated pages
• unclear authorization
• too many Dynamic Actions
• unnecessary modal dialogs
• an application that becomes harder to understand as it grows

In my experience, a little planning before opening Page Designer saves a lot of restructuring later.

Start with the data model

For the original presentation, I used the Oracle HR schema.

It contains familiar entities such as:

• Employees
• Departments
• Locations
• Countries
• Regions

This is a simple model, but it is enough to illustrate an important point:

application structure should reflect both the relationships in the data and the way users work with that data.

The first question is therefore not:

Which APEX page type should I create?

It is:

How does the user move through the business information?

The simplest navigation model

A first version of the application might look like this:

Home
├── Employees
│   └── Employee Data
├── Departments
│   └── Department Data
├── Locations
│   └── Location Data
├── Countries
│   └── Country Data
└── Regions
    └── Region Data

This is straightforward.

Every entity gets a list page and a detail page.

For a small application, this can already work well.

But business applications rarely remain this simple.

Master-detail relationships change navigation

Consider Departments and Employees.

A department is not only an independent record.

It also has employees.

Instead of forcing users to return to the Employees menu and search again, it is much more natural to allow them to navigate directly:

Department
    ↓
Department Data
    ↓
Department Employees
    ↓
Employee Data

The application begins to reflect the actual relationship between the data.

The same idea can be extended further:

Region
    ↓
Countries
    ↓
Locations
    ↓
Departments
    ↓
Employees

This is much closer to how users often think about business data.

Think in user journeys, not only pages

A common mistake is to design an APEX application as a collection of isolated pages.

The better question is:

What path will the user follow?

For example:

Regions
→ Region
→ Countries in Region
→ Country
→ Locations in Country
→ Location
→ Departments at Location
→ Department
→ Employees in Department
→ Employee

Once this flow is clear, several design decisions become easier:

• which pages should exist
• which pages can be reused
• where links should appear
• what should be shown as related information
• which actions should return the user to the previous context

The application becomes a connected system rather than a collection of separate screens.

Reuse pages where possible

One of the things I explicitly warned against in the original presentation was:

duplicated pages.

It is tempting to create a separate Employee page for every context:

• Employee from the Employees menu
• Employee from a Department
• Employee from Search
• Employee from another report

Usually, this is unnecessary.

A better design is to reuse the same page and pass the appropriate record ID and context.

This reduces:

• duplicated logic
• duplicated validations
• maintenance effort
• inconsistent behavior

The more business logic a page contains, the more important reuse becomes.

Master-detail is a design concept

When I say master-detail, I am not necessarily talking about one specific APEX page type.

I am talking about the relationship between business objects and the way users navigate between them.

There are several ways to represent these relationships in APEX:

• master-detail pages
• related reports
• tabs
• regions
• links
• cards
• Interactive Reports
• modal dialogs

The important decision comes before the component choice.

First define:

what information belongs together and how the user should move between it.

Then choose the APEX components that best support that flow.

Plan authorization early

Authorization should not be something we add at the very end of the project.

Even a simple application can quickly develop several permission levels.

For example:

Login
├── Data View
├── Data Edit
├── Parameter View
└── Parameter Edit

These permissions affect much more than buttons.

They may determine:

• which pages are visible
• which menu entries appear
• which regions are rendered
• which actions are available
• which data can be modified

If authorization is considered only after the application is already built, the existing structure may make permission management unnecessarily difficult.

Navigation and authorization belong together

A page may technically exist while being unavailable to a particular user.

That is often correct.

But the navigation should reflect the same authorization model.

For example, if a user cannot maintain parameters, there should usually be no visible navigation path leading to parameter maintenance.

This sounds obvious, but in larger applications inconsistent menu and page authorization can become confusing very quickly.

Planning both together avoids this.

Standardization matters

Another key point in the original talk was:

standardize as much as possible.

Oracle APEX already gives us an important advantage through Universal Theme.

Use that advantage.

Standardization can include:

• page layouts
• report behavior
• button placement
• dialog behavior
• navigation patterns
• naming conventions
• templates
• validation patterns
• authorization schemes

Users should not have to learn the same application again on every page.

Developers should not have to rediscover how every page was built.

Universal Theme is more than visual design

Universal Theme is often treated mainly as a visual layer.

I think it is more useful to view it as a shared design vocabulary.

When standard components already solve a problem, creating a custom implementation should require a reason.

Custom JavaScript and CSS are sometimes necessary.

But every custom solution also creates something developers need to understand, test and maintain later.

Consistency is especially valuable in large business applications.

Five things I try to avoid

The original presentation ended with a short DON'T DO list.

These were the five points.

1. A modal dialog opening another modal dialog

A modal can be very useful.

A chain of modal dialogs usually is not.

Users can quickly lose track of:

• where they are
• what they are editing
• what happens when they close a dialog
• which page owns the current state

If a workflow becomes that deep, it may deserve a normal page.

2. Duplicate pages

Avoid creating nearly identical pages for slightly different navigation paths.

Reuse the same page when the business function is the same.

Otherwise every later change may have to be repeated in several places.

3. Excessive Dynamic Actions

Dynamic Actions are powerful.

That does not mean every piece of application behavior should become a Dynamic Action.

If a page contains many interacting client-side actions, understanding its behavior becomes increasingly difficult.

Use Dynamic Actions where they make the interaction clearer, but keep the overall application flow understandable.

4. Missing navigation

A technically working page is not automatically a usable application.

Users need to understand:

• where they are
• how they arrived there
• where they can go next
• how they can return

Navigation is part of application design, not decoration.

5. Missing grouping

As applications grow, flat menus and long page lists become difficult to understand.

Group related functions.

This can be done through:

• navigation hierarchy
• menus
• cards
• page groups
• functional modules
• consistent naming

Structure becomes increasingly valuable as the number of pages grows.

Plan before Page Designer

The main message of my 2023 presentation was simple:

do not let the speed of Oracle APEX development replace application design.

APEX allows us to create pages extremely quickly.

That makes planning more important, not less.

Before building an application, I try to answer questions such as:

1. What are the main business objects?
2. How are they related?
3. What are the main user journeys?
4. Which pages can be reused?
5. What authorization levels exist?
6. How should navigation reflect those permissions?
7. Which UI patterns should be standardized?

Once these questions are reasonably clear, Page Designer becomes much easier to use effectively.

A simple planning model

For many applications, the planning process can be summarized like this:

Data model
    ↓
Business objects
    ↓
Relationships
    ↓
User journeys
    ↓
Pages
    ↓
Navigation
    ↓
Authorization
    ↓
Standardized UI

The exact implementation may change.

The sequence of thinking is what matters.

Build quickly, but design deliberately

Oracle APEX gives developers an unusually fast way to turn database structures into working business applications.

That speed is a major advantage.

But speed should not mean that architecture, navigation and usability are decided accidentally while pages are being created.

A few minutes spent drawing relationships and user journeys before development can prevent much more expensive restructuring later.

That is one of the principles I have continued to use when building larger Oracle APEX applications:

build quickly, but design deliberately.

Looking back at 2023

In October 2023, I published an article in Hungarian about generative AI in application development.

At the time, many of the ideas discussed here were still expectations about where low-code and AI might take us.

Three years later, it is interesting to look back at what actually happened.

Read the original Hungarian article →

In 2023, generative AI was already changing the way we thought about software development.

My main interest was not whether AI could write code.

The more interesting question was whether it could change the relationship between business users, developers and the applications they build together.

That question still matters today.

The problem existed long before generative AI

For many years, I have worked with business teams that were not simply users of enterprise software.

They understood their processes deeply and often knew exactly what would make their daily work more efficient.

The traditional software development model, however, creates a difficult translation problem:

the business user describes a requirement, the developer interprets it, builds something, and the user later decides whether the result actually solves the original problem.

This takes time.

And while the software project is progressing, users often create their own solutions using spreadsheets, small databases or other tools.

This is one of the reasons low-code platforms became interesting to me long before the current AI wave.

Low-code had already started changing the boundary

Oracle APEX allows applications to be built close to the data, using a largely declarative development model.

A developer — and in some cases an experienced business user — can create useful applications without building an entire technology stack from scratch.

In my 2023 article, I argued that generative AI could push this idea significantly further.

Instead of selecting components and manually writing every SQL statement, developers could increasingly describe what they wanted in natural language.

For example:

Show the average salary of employees by department.

The development environment could use information about the database structure to generate the SQL needed for the report or chart.

At the time, this felt like an important next step.

From natural language to SQL

One of the examples I discussed in 2023 was an AI assistant helping generate SQL based on a natural-language request.

The important part was not only the language model itself.

The model also needed context:

• available tables

• columns and data types

• primary keys

• foreign keys

• relationships between database objects

Without this context, an LLM only knows SQL.

With the context, it can begin to understand your application and your data model.

This distinction is even more important today.

What happened next?

By 2026, AI support in Oracle APEX has moved considerably beyond the experiment I described in 2023.

APEX Assistant can help developers work with SQL directly inside the development environment.

Generative AI can also be used during application creation.

But perhaps the most interesting development for me is that AI-assisted development is moving beyond generating individual pieces of SQL or PL/SQL.

It is beginning to work with the structure of the application itself.

APEXlang changes the discussion

Oracle APEX 26.1 introduced APEXlang, an open, human-readable representation of an APEX application.

This is important for AI-assisted development.

Instead of treating an APEX application only as something configured through Page Designer or represented by a large SQL export, developers and AI tools can work with a structured application definition.

This makes new workflows possible:

• AI-assisted application generation

• reviewing proposed application changes

• version control

• validation

• application comparison

• controlled modification of pages and components

• collaboration between external AI coding agents and APEX

The AI is no longer helping only with a SQL statement.

It can increasingly help work with the application model itself.

From prompt to specification

Another important change is the move from simple prompting toward structured specifications.

For enterprise applications, saying:

Build me an application for managing customers.

is rarely enough.

Real systems have:

• roles

• workflows

• validations

• security rules

• integrations

• data models

• business constraints

• existing applications and processes

The better the specification and context we provide, the more useful AI becomes.

This is why I think AI-assisted development will increasingly become specification-driven development rather than simply prompt-driven coding.

AI does not remove the need for structure

This is probably the biggest difference between how I thought about the subject in 2023 and how I think about it today.

In the early generative AI discussion, the emphasis was often on what AI could generate.

Today, I think the more important questions are:

• Can we understand what was generated?

• Can we validate it?

• Can we maintain it?

• Can we safely modify it?

• Can we integrate it with existing systems?

• Can we govern the development process?

Generating software is becoming easier.

Maintaining reliable enterprise software is not.

Why low-code may become more important, not less

It might seem logical that if AI can generate code, low-code platforms become less important.

I increasingly think the opposite may happen.

AI can generate almost unlimited amounts of code.

But more code also means more complexity to understand, test and maintain.

A declarative platform provides an abstraction layer.

Instead of asking AI to generate every technical implementation detail, we can describe the application's intent within a defined application model.

This is where I believe platforms such as Oracle APEX become particularly interesting in an AI-driven development world.

The user and developer move closer together

One idea from my 2023 article has become even more relevant.

The boundary between:

• developer and user

• IT and business

• supplier and customer

continues to become less rigid.

AI allows people to express requirements more directly.

Low-code provides a controlled environment in which those requirements can become applications.

The developer's role does not disappear.

It changes.

More attention moves toward:

• architecture

• data

• security

• integration

• validation

• governance

• maintainability

and less toward manually producing every line of implementation code.

Looking back

When I wrote about generative AI and APEX in 2023, I mainly saw AI as a new way to help developers and users communicate with the application platform.

Three years later, that idea has expanded considerably.

We are moving from:

natural language → SQL

toward:

requirements → specification → application model → validated application

That is a much bigger change.

And I think we are still near the beginning.

My broader professional journey has followed a similar path:

Database → APEX → Cloud → AI

The technologies keep changing.

The central question remains remarkably consistent:

How can we turn business knowledge and data into reliable software more effectively?

Updated from 2023

This article is an updated English version of a post I originally published in Hungarian in 2023. Read the original Hungarian version →

Oracle APEX does an excellent job of supporting declarative application development.

In Page Designer, we can build a page using components, configure their properties, add a few processes or validations, and very quickly have a working business application.

But sometimes we want to execute server-side logic without submitting and rebuilding the whole page.

This is where AJAX becomes useful.

In this example, I will show how to call a PL/SQL process from JavaScript using apex.server.process, pass a value to the server, update data in the database, and refresh only the affected region.

The example

Let's use a very simple Classic Report showing employees and their salaries.

When the user clicks a salary value, we want to:

1. identify the employee,

2. call a server-side PL/SQL process,

3. double the employee's salary,

4. return control to the browser,

5. refresh the report.

There is no full page submit.

1. Make the report value clickable

Assume our Classic Report query returns:

• EMPLOYEE_ID

• SALARY

Instead of using an inline JavaScript handler, we can give the link a CSS class and store the employee ID in a data attribute.

In the HTML Expression of the Salary column:

<a href="#" class="js-salary" data-employee-id="#EMPLOYEE_ID#">#SALARY#</a>

The report now renders the salary as a clickable value.

The data-employee-id attribute contains the ID of the employee whose salary we want to update.

2. Create a Dynamic Action

Create a Dynamic Action with:

• Event: Click

• Selection Type: jQuery Selector

• jQuery Selector: .js-salary

Because the report will later be refreshed, configure the event so that it also works for dynamically refreshed report rows.

For the True Action, choose Execute JavaScript Code.

Use:

const employeeId = this.triggeringElement.dataset.employeeId;

console.log("Employee ID:", employeeId);

apex.server.process(
    "PROC_SALARY",
    {
        x01: employeeId
    },
    {
        dataType: "text",

        success: function (pData) {
            console.log("Server response:", pData);
            apex.region("myREPORT").refresh();
        },

        error: function (jqXHR, textStatus, errorThrown) {
            apex.debug.error(
                "PROC_SALARY failed",
                textStatus,
                errorThrown
            );

            apex.message.alert("The salary update failed.");
        }
    }
);

The important part is:

apex.server.process("PROC_SALARY", ...)

This calls an APEX Ajax Callback named PROC_SALARY.

We pass the employee ID using:

x01: employeeId

On the server side, APEX exposes this value through:

apex_application.g_x01

3. Create the PL/SQL Ajax Callback

Create an Ajax Callback process named:

PROC_SALARY

The PL/SQL code can look like this:

begin
    update oehr_employees
       set salary = salary * 2
     where employee_id = to_number(apex_application.g_x01);

    commit;

    htp.p('ok');
exception
    when others then
        rollback;
        apex_debug.error('PROC_SALARY failed: %s', sqlerrm);
        raise;
end;

The value passed from JavaScript in x01 is available through:

apex_application.g_x01

We use it to identify the employee whose salary needs to be updated.

The callback sends a simple text response back to JavaScript:

htp.p('ok');

Because the JavaScript call specifies:

dataType: "text"

the returned value is available in the success function as pData.

4. Refresh only the report

If the server-side process completes successfully, we execute:

apex.region("myREPORT").refresh();

For this to work, set the Classic Report's Static ID to:

myREPORT

Only the report is refreshed.

The rest of the page remains unchanged.

The complete flow is therefore:

User clicks Salary
        ↓
Dynamic Action
        ↓
apex.server.process
        ↓
PROC_SALARY Ajax Callback
        ↓
UPDATE in Oracle Database
        ↓
Response returned to JavaScript
        ↓
Classic Report refresh

Why use AJAX?

The main advantage is that we do not need to submit and reload the entire page just to execute a small server-side operation.

This can provide a smoother user experience for operations such as:

• changing a value,

• executing a small PL/SQL operation,

• validating data,

• retrieving server-side information,

• refreshing part of a page,

• triggering business logic from a user action.

It also allows us to combine APEX's declarative development model with JavaScript when we need more control over the interaction.

What changed since the original 2023 version?

The core idea of the original article remains valid.

apex.server.process is still a useful way to call server-side APEX processes from JavaScript.

However, I would implement the client-side part differently today.

My original example used JavaScript directly inside the report link. In modern APEX applications, I prefer separating markup from behavior and using Dynamic Actions or dedicated JavaScript code instead.

This makes the application easier to understand, maintain and change later.

Error handling is another area worth making explicit.

A real application should not assume that every AJAX request succeeds. Both the client and server side should handle unexpected errors appropriately.

AJAX is not the same as background processing

There is also an important distinction.

Although the PL/SQL process executes without a full page submit, this is still a request-response operation.

The browser sends the AJAX request and waits for the server-side process to finish.

For short operations, this is exactly what we want.

For genuinely long-running tasks — imports, large calculations, integrations or batch processing — a real background execution mechanism is usually more appropriate.

That may involve APEX background processing capabilities or database mechanisms such as DBMS_SCHEDULER.

So the question is not simply:

How can I run PL/SQL in the background?

A better question is:

Does the user need to wait for the result, or should the work continue independently of the browser request?

That distinction becomes increasingly important as APEX applications grow from simple pages into larger enterprise systems.

Conclusion

One of the strengths of Oracle APEX is that we can start with declarative development and add lower-level control only where we actually need it.

apex.server.process provides a simple bridge between browser-side JavaScript and server-side PL/SQL.

For small interactive operations, it allows us to:

JavaScript → PL/SQL → Oracle Database → refresh only what changed

without submitting the whole page.

It is a small technique, but one I have used repeatedly in real APEX applications.

Since I am developing an APEX application to manage multiple databases, I needed a function that could generate a new password for a user and send it to a given email address.

In my case, I am working with OCI Autonomous Transaction Processing (ATP) databases, where users are assigned to the DEFAULT profile:

SELECT profile, resource_name, limit
FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_type = 'PASSWORD';

The password rules are validated by the CLOUD_VERIFY_FUNCTION:

SELECT text
FROM dba_source WHERE name = 'CLOUD_VERIFY_FUNCTION' ORDER BY line;

From the code, we can see that complexity is checked through the call: ORA_COMPLEXITY_CHECK(password, 12, null, 1, 1, 1, null);

This means the password must be at least 12 characters long and contain at least one lowercase letter, one uppercase letter, and one number.
But what about special characters?

The DEFAULT user profile does not enforce them, but for security reasons I wanted to ensure that generated passwords also contain at least one special character.

After checking the ORA_COMPLEXITY_CHECK function itself:

SELECT text
FROM dba_source WHERE name = 'ORA_COMPLEXITY_CHECK' ORDER BY line;

My Password Generator

I created my own password generator function using the DBMS_RANDOM package:

create function f_pwd_gen(p_length number default 20) return varchar2 as
    a number:=0;
    k number;
    i number;
    r varchar2(100); -- result
    v_check varchar2(100);
begin
    loop
      -- The password must begin with a character!
      a:=a+1; -- iteration counter
      r:=upper(dbms_random.string('u',1));
      v_check:='';
      
      for k in 2..least(p_length,100) loop -- max 100 chars
          i:=round(dbms_random.value(0,9));  
          if i between 0 and 3 then -- lower
            r:=r || lower(dbms_random.string('u',1));
            v_check:=v_check || 'L';
          elsif i between 4 and 6 then -- upper
            r:=r || upper(dbms_random.string('u',1));
            v_check:=v_check || 'U';              
          elsif i between 7 and 8 then -- number
            r:=r || lower(round(dbms_random.value(0,9)));
            v_check:=v_check || 'N';              
          else -- special
            r:=r || SUBSTR('#$_', dbms_random.value(1, 3), 1);
            v_check:=v_check || 'S';              
          end if;  
      end loop;  
      
      -- Replace potentially misleading characters
      r:=replace(r,'o','f');  
      r:=replace(r,'0','3');                
      r:=replace(r,'O','G');    
      r:=replace(r,'l','t');    

      exit when a>100 
        or (instr(v_check,'L')>0 and instr(v_check,'U')>0 
        and instr(v_check,'N')>0 and instr(v_check,'S')>0 );
   end loop;   

   return r;
end;

At first, I tried including as many symbols as possible in the “special character” line. However, when setting the new password, I constantly received error messages.

The Real Issue

Passwords are usually set with a command like:

ALTER USER SCOTT IDENTIFIED BY fsd32fasSD_FS;

If you don’t wrap the password in quotes, the SQL parser interprets many special characters incorrectly. That’s why it may look like only #, $, or _ are allowed.

✅ The fix is simple: enclose the password in double quotes. (Of course, I only realized this much later.)

ALTER USER SCOTT IDENTIFIED BY "N3w!Pass@2025";

When quoted, Oracle accepts almost any character (except the double quote " itself and the null character).

⚠️ Be aware that some shells and tools (SQL*Plus, terminals, scripts) interpret certain characters (!, &, \) before they reach the database. In those cases, escape them at the client level or use EXECUTE IMMEDIATE in PL/SQL to set the password.

Conclusion & Best Practices

Even though Oracle’s ORA_COMPLEXITY_CHECK function doesn’t require special characters by default, you can and should include them for stronger security. The key is to quote your password in the ALTER USER statement so all special characters are accepted.

If you’re building workflows in Oracle APEX (or any automation around database password resets), keep in mind:

• Always quote the password in ALTER USER.

• Test which characters your client environment accepts without extra escaping.

• Replace ambiguous characters (O, 0, l) to avoid confusion.

• Consider sending passwords securely.

• Require users to change their generated password upon first login.

👉 By quoting the password properly, you can safely generate and use strong passwords containing a full range of special characters.

Of course, I didn’t start from scratch. As an active OCI user, I already had practical experience. But going through the official materials filled in many gaps and connected the dots between different services in a way that hands-on troubleshooting alone couldn’t.

From Books to On-Demand Learning

Over the past ten years, I’ve taken several Oracle certifications, and the process has changed dramatically. For my very first exam, I ordered a book from Amazon, studied it cover to cover, and still passed only on the second attempt. At the time, official Oracle courses were out of reach — a full week, thousands of dollars in cost, and of course, mandatory travel. The exam itself meant going to a test center, emptying your pockets, and being watched by four cameras.

Fast forward to today: the process is simpler, faster, and more accessible. Many Oracle University courses and exams are free until October 31, 2025 in the Race to Certification 2025 program.

The quality of the learning materials is excellent — well-paced, well-illustrated, and supported with practice questions.

I also appreciated that the same Oracle University content is available on LinkedIn Learning. The platform’s transcript view made it easy to jump to exactly the right moment in each video, and with AI I could generate quick summaries and clarifications—even in Hungarian—when I wanted a different explanation. The courses are subtitled in 30+ languages, which lowers the barrier for non-native speakers (even though the exam itself is in English). Combined with the clear pacing and visuals, that made my study sessions faster and far more focused.

The training is subtitled in more than 30 languages, which makes it even more approachable globally.

Exam Details

• Exam Code: 1Z0-1085-25

• Format: 40 multiple-choice questions

• Duration: 60 minutes

• Passing Score: 65%

• My Score: 80% (completed in ~25 minutes)

Each question has four possible answers, and there’s always exactly one correct choice. In my experience, at least half of the questions were very similar (sometimes identical) to the ones in the official practice test. The practice test is particularly useful because it shows you where you made mistakes — unlike the real exam, where you only see the final score.

Another big advantage: you get 15 free attempts at the exam. That removes a lot of the pressure and gives you room to practice until you feel confident.

Final Thoughts

If you’re already using OCI, I strongly recommend taking the OCI Foundations Associate exam. Not only will you gain a clear, structured view of the platform, but you’ll also be better equipped to explain OCI to colleagues, customers, and decision-makers. For me, the certification wasn’t just a badge — it was a way to step back from day-to-day problem solving and build a more complete mental model of Oracle Cloud.

I walked away with a stronger foundation, a certification to show for it, and plenty of motivation to continue down the OCI certification path.

The question is how to separate the objects of each system within a tenancy in the Oracle Cloud. Or how can we give them individual, external access? In OCI we can assign privileges to registered users. However, we do not want each (technical) user to have access to the resources of another.

Architecture

In my architectural approach, a client has an APEX application (Application A). Each application has a separate workspace and a separate schema. It helps a lot to keep the architecture clean that each application, system, client, whatever you want to call it, is given an alias.

For example, Global Network Application has the alias GN. So the schema name is GN_PROD, the workspace is GN_PROD_WKS, and the application alias is GN. And in the DEV environment, GN_DEV, GN_DEV_WKS.

Following the logic above, each system also gets its own compartment (in our case, GN_Compartment).

Here, the DEV and PROD environments share the OCI resources. A bucket (GN_Bucket) is created under each compartment. The files created by the live and development environments can be separated within the bucket.

What about privilege management?

In OCI, permission roles are managed by policies. I created this policy in the root compartment, in our case called GN_ADMIN_POLICY.

I also created a special user group to which I added the system administrators and the technical user. GN_ADMIN_POLICY has the following policy statement:

Allow group GN_ADMIN_GROUP to manage all resources in compartment GN_compartment

This gives all members of GN_ADMIN_GROUP read and write access to GN_Bucket in GN_compartment.

Creating a technical user

In OCI, a user must have a unique email address. At least I did not find an alternative solution. For me, the problem was that as a Google Workspace subscriber, each new email address or user is a significant additional monthly cost.

Fortunately, Google allows up to 30 variations of an email address. So I didn't have to create the technical users as new Google users, that was enough in OCI.

Of course, there are many other combinations possible to separate permissions, but as a PROD and DEV ATP user, this seems to be the best solution.

The first major difficulty was understanding the administration. As database and APEX application developers, the four things we need to focus on most when it comes to administration are:

• Server

• Database

• APEX instance

• APEX workspace and users

Server

As I mentioned in the previous article, as developers, we don't really want to be involved in administration. This is why using cloud-based services is a good choice. To get started, there is nothing extra to do other than subscribe. After registration, an Administrators group is created and we immediately become members of it.

The management and allocation of privileges is done through groups. The group can be found under Identity & Security/Domains/Default domain/Groups where you can add users to the group.

And we need to assign policies to the groups. The policies contain the privileges themselves. Policies can be found under Identity & Security/Policies.

Of course, as I wrote, initially we get admin rights and we can do anything in the cloud. However, once we want to add more users and not with administrator rights, we need more understanding.

Database administration

By going into the Oracle Database/Autonomous Database menu, we have to click on our database - I only have one - and we are taken to the database administration.

Here, clicking on Database Actions/Database Users will bring up the default database users, including ADMIN.

Here it is important that Web access is enabled (it is enabled for ADMIN) so that we can open an SQL window.

The ADMIN user has the rights of the classic SYS user and is therefore the main administrator. It allows you to create and manage additional users and privileges.

APEX Instance

APEX instance administration can be accessed via the Database Actions/View all database actions/APEX menu.

In the cloud, the administration of APEX users is very different. After a few hours of trying, I managed to understand the logic of this. When creating a workspace, you have to specify whether you want to use an existing schema or create a new one.

New Schema

When creating a new schema, we do not have the option to specify its name.

The logic surrounding the workspace username and password in Oracle's APEX can indeed be complex. Here's a simplified explanation:

1. Existing Database User:

   • If the workspace username (e.g., DPATAKI) already exists as a database user, the workspace will link to this existing database user.

   • To log into the workspace, use the database password associated with this username.

   • The workspace password you set will be used for the APEX user within the applications created in the workspace.

2. New Database User:

   • If the workspace username does not exist in the database, a new database user is created.

   • In this case, the database password and the APEX password will be the same as the one you set during workspace creation.

3. Privileges:

   • A new user created by an APEX workspace in the database will not automatically have privileges to create connections.

This setup ensures that the database and APEX environments are securely linked while maintaining separate authentication mechanisms for database access and APEX application access.

Existing Schema

I prefer to create the schema first as a database administrator and here only the new workspace associated with it. The reason for this is that the naming conventions I use for schema names are very important to me.

The logic here is the same as in the previous point. The interesting thing is that the database user and the workspace username can be the same.

APEX workspace and users

It logically follows from the previous section that you can only access the APEX workspace with a database name and password. Let's say the login screen shows that this is the case, I just didn't notice it.

In the APEX workspace, the three levels of privilege—Administrator, Developer, and User—function similarly in both on-premises and cloud environments.

However, in the cloud, when you add an Administrator or Developer to a workspace, a database schema is automatically created for them. This automatic creation of a schema can be confusing, but it is likely designed to ensure that each Administrator or Developer has a dedicated space for their work, enhancing security and organization.

On the other hand, creating a simple User does not result in a new schema; the User exists only within the APEX workspace, which simplifies user management for non-development roles.

Our larger customers provide on-premise environments and handle their own database administration tasks. For our smaller customers, we rely on an independent cloud provider for hosting, allowing us to focus on development.

Both solutions have their limitations.

In the second case, we also use Oracle XE, which is an extra limitation. Still, we were able to operate without Oracle Cloud Infrastructure for a very long time.

But because of a new project we had, I made the decision to go ahead with our own Autonomous Transaction Database (ATP) subscription.

This seems like a good decision for the following reasons:

1. No need to handle maintenance.

2. Although it's not cheap, once we purchase the license, the cost of further growth is significantly lower.

3. Dynamic processor count and cheap storage space.

4. I can consolidate multiple Oracle XE databases under a single ATP subscription.

5. Scheduled backups and quick restoration.

6. Local (Hungarian) support.

7. Access to the entire ecosystem in the cloud.

The move

However, the transition to OCI and learning how to use it were slower and more challenging than I expected. One thing that became clear was that it's better to work with Oracle through a key account manager, as this provides better support. This process takes more time (for us, it was two weeks), and you need to pay in advance for about a year (5000 EUR + VAT). You can start the process on the Oracle website.

Another important point is that it's not worth subscribing without immediately upgrading to a paid plan. Unfortunately, there was a data loss that support could not (or would not) resolve because the environment was free.

When estimating the cost, remember to select "license included" for the license type if you don't have your own license (BYOL option). This way, you won't face unexpected charges later. Currently, I'm looking at a cost of 500-600 EUR per month, which is worth it if I can move two or three clients. With the current provider, there is no license fee because they use Oracle XE, but there is a significant cost for support and operations.

In the next section, I will talk about database administration and how to manage users.

I've seen several presentations on how Select AI works at various APEX conferences. However, they were very simple, mostly formulating queries on a table (in English) and getting answers (in SQL) using some kind of language model.

Basically, I am curious about three things:

1. How Select AI handles complex queries?

2. How different language models (Cohere, OpenAI) deal with complex queries?

3. How to integrate Select AI with an on premise application and what results are obtained with metadata and queries written in Hungarian?

In this article I will explore the first point using OpenAI's language model. For now, Select AI only works within OCI, so I have created an app with the necessary settings where I can ask questions.

In the schema, I populated the HR schema tables using APEX Sample Datasets.

The HR schema data model looks like this:

Start testing Select AI

Let's start with a simple question:

"Show me the details of the employee with the highest salary."

This solution may not be the most beautiful, so you can ask it to use an analytic function, for example.

"Show me the details of the employee with the highest salary. Use an analytic function in the solution."

SELECT e.employee_id, e.first_name, e.last_name, e.salary
    FROM (
    SELECT employee_id, first_name, last_name, salary,
    RANK() OVER (ORDER BY salary DESC) AS salary_rank
    FROM employees) e
WHERE e.salary_rank = 1

Since I would like to look at the table connections, let's ask what the salaries look like by departments:

"List the amount of salary per department!"

SELECT d.DEPARTMENT_NAME, SUM(e.SALARY) AS TOTAL_SALARY
FROM ENROLOCI.DEPARTMENTS d
    JOIN ENROLOCI.EMPLOYEES e ON d.DEPARTMENT_ID = e.DEPARTMENT_ID
GROUP BY d.DEPARTMENT_NAME

Let's go through the data model up to the highest aggregation, the regions.

"List the amount of salary per location!"

Error.

"List the amount of salary per department and location!"

SELECT d.DEPARTMENT_NAME AS "Department", l.CITY AS "Location", 
        SUM(e.SALARY) AS "Total Salary"
FROM ENROLOCI.DEPARTMENTS d
    JOIN ENROLOCI.LOCATIONS l ON d.LOCATION_ID = l.LOCATION_ID
    JOIN ENROLOCI.EMPLOYEES e ON d.DEPARTMENT_ID = e.DEPARTMENT_ID
GROUP BY d.DEPARTMENT_NAME, l.CITY

After referring in the question to the table between location and salary, the department, we managed to get a good answer to the question.

"List the salaries by country!"

Error.

"List the salaries by country! Use foreign keys!"

Error.

(This model's maximum context length is 4097 tokens. However, you requested 4237 tokens (3213 in the messages, 1024 in the completion). Please reduce the length of the messages or completion.)

Let's try another way.

List the sum of employees' salary by country! Use foreign keys!

SELECT COUNTRY.COUNTRY_NAME, SUM(EMPLOYEES.SALARY) AS TOTAL_SALARY
FROM ENROLOCI.COUNTRIES COUNTRY
    JOIN ENROLOCI.LOCATIONS LOCATION ON COUNTRY.COUNTRY_ID = LOCATION.COUNTRY_ID
    JOIN ENROLOCI.DEPARTMENTS DEPARTMENT ON LOCATION.LOCATION_ID = DEPARTMENT.LOCATION_ID
    JOIN ENROLOCI.EMPLOYEES EMPLOYEES ON DEPARTMENT.DEPARTMENT_ID = EMPLOYEES.DEPARTMENT_ID
GROUP BY COUNTRY.COUNTRY_NAME

Finally, there was no need to list the tables between salary and country. However, I had to specify that the salary belonged to the workers' table and instructed them to use the foreign keys.

"List the sum of employees' salaries by region!"

Interestingly, I didn't have to ask to use foreign keys here, I got the correct result anyway. I assume the AI has learned from your mistakes.

Conclusion

To be fair, the HR schema tables are very well populated with comments.

Let's look at the employees and departments tables for example:

comment on table EMPLOYEES
  is 'employees table. Contains 107 rows. References with departments, 
jobs, job_history tables. Contains a self reference.';

comment on table DEPARTMENTS
  is 'Departments table that shows details of departments where 
      employees work. Contains 27 rows references with locations, 
      employees, and job_history tables.';

The comment in the salary field is as follows:

comment on column EMPLOYEES.salary
  is 'Monthly salary of the employee. Must be greater than zero 
      (enforced by constraint oehr_emp_salary_min)';

Of course, the number of questions is endless, with countless possibilities for testing. However, I think Select AI is a good solution to use, although the metadata descriptions need a lot of testing and tuning.

At the same time, I see Select AI as very promising in its ability to evolve.

Október 11. már hét éve az Oracle fejlesztői közösség napja, ilyenkor sokan igyekeznek posztolni olyan témákban, melyek a közösséghez kapcsolódnak. Két éve ez a nap Joel Kallman emlékére lett átnevezve, aki igazi úttörőként vett részt az Oracle Application Express (APEX) létrehozásában és fejlesztésében.

Sajnos személyesen nem találkozhattunk, de a Covid alatt számos online előadáson vehettem részt, ahol ő is az előadók között volt.

Én személy szerint is sokat kaptam az APEX fejlesztői közösségtől, külföldi útjaim során nagyon nyitott és támogató embereket ismerhettem meg. Olyanokat, akik lelkesednek a munkájukért, akik szeretik azt, amit csinálnak.

Higyjétek el, programozók, fejlesztők között ez közel sem mondható el mindenkiről. Sokan csak azért választották ezt a szakmát, hogy ne kelljen emberekkel beszélni, kommunikálni, a problémáikkal foglalkozni.

Remélem a különböző APEX konferencákon készített képeim is arról tanúskodnak, hogy az APEX fejlesztők nagyon nyitottak és támogatóak.

Ugyanakkor nemcsak külfölfön találkozhatsz velük, hanem már kis hazánkban is elkezdtünk szerveződni. A következő meetupunkra például itt tudsz jelentkezni.

A képek helyszínei sorrendben: London (UK), Maribor (SLO), Zeist (NL), Stockholm (S), Zagreb (HR), Oslo (N), Budapest (HU)

Végül pedig egy interjú:

Az alap működés során azonban az oldalunkat minden Submit vagy Redirect után újra elkérjük a szervertől, tehát az egész oldalunk újraépül. Ilyenkor a kurzor pozíciók elveszhetnek és a felhasználói élmény is romlik.

Ebben a postban bemutatom a háttérben történő eljáráshívást (AJAX) az APEX környezetben.

A példánkban egy egyszerű Classic Report cellájának értékére kattintva szeretném a megjelenített értéket megduplázni.

A megoldás menete a következő lesz:

1. Kattinthatóvá tesszük az értékeket

2. Kattintás esetén meghívásra kerül egy Javascript függvény

3. A függvény meghív egy PL/SQL Page process-t

4. Végrehajtjuk az érték duplázását egy SQL utasítással

5. Frissítjük a riportot az új eredménnyel

A Classic Report most az SQL utasításunk eredményeképpen kapott Salary oszlopot jeleníti meg. Írjuk be az oszlop HTML Expression tulajdonságába a következőt:

<a href="javascript:onlcick=f_salary(#EMPLOYEE_ID#);">#SALARY#</a>

Figyeljük meg, hogy a riportunkban a Salary oszlop kattinthatóvá válik. Kattintás esetén meghívja az f_salary() javascript függvényt, ami még nem létezik, ezért hozzuk létre az oldal tulajdonságai között a Function and Global Variable Declaration részben.

function f_salary(id) {
   console.log("id: " +id);
   apex.server.process('PROC_SALARY',
            {x01:id},
            {dataType: 'text',
                success: function(pData)
                            {
                                console.log("Eredmény: "+ pData );
                                apex.region("myREPORT").refresh();             
                            }
            }                
                        );
    };

A függvény bemenő paramétere az Employee_id oszlop értéke, erre majd az adat frissítésénel lesz szükségünk, hiszen innen tudjuk majd, hogy melyik dolgozó fizetésére történt a kattintás.

A console.log utasítással szövegeket tudunk a böngésző konzol ablakába kiíratni, aminek a megoldás szempontjából nincs jelentőssége, a hibakeresésnél azonban hasznos lehet tudni, hogy hol is járunk a futásban.

Az apex.server.process beépített javascript utasítás első paramétere az az oldal vagy applikáció szintű PL/SQL process, amit a javascript függvényünk meghív. Most csak egy paramétert adunk át, az X01 pozícióban. A dataType a visszatérési érték típusát adja meg, amely alapesetben Json, de mi most csak egy karaktersorozatot várunk, ezért text. (A visszatérési értéknek a példánkban nincs jelentősége, csupán ez is kiíratásra kerül a konzolra.)

Ha sikeresen lefutott a háttérben a PROC_SALARY process, akkor az apex.region("myREPORT").refresh(); javascript utasítással frissítjük a riportunkat. A riportra egy azonosítóval hivatkozunk - esetünkben myREPORT - amit a Classic Report régió Static ID tulajdonságánál állítottunk be.

A PROC_SALARY eljárás kódja a következőképpen néz ki:

begin
update oehr_employees set salary=salary*2 
where employee_id=apex_application.g_x01;
commit;
    htp.p('ok');
end;

Maga az eljárás az oldal AJAX Callback részénél került létrehozásra, mivel az nem kötődik az oldal valamely eseményéhez.

A Javascript, kliens oldali hívás paraméterét az apex_application.g_x01 függvény adja vissza, így ezt fel tudjuk használni az SQL utasítás szűrési paramétereként.

A htp.p utasítással pedig visszatérési értéket adhatunk az AJAX call-nak.

A kliens oldali kódok kis- és nagybetű érzékenyek, ha ebben hiba van, nem fog futni a kódunk!

A megoldás kipróbálható az alábbi linken:

https://apex.oracle.com/pls/apex/r/test_sqelme/enrolblog/home

Kezdő lépésként egy meetup-al indítanánk, ahol személyesen is meg tudunk ismerkedni.

A tervezett program:

• A classic riport rejtett lehetőségei

• Hol teheted fel a kérdéseidet vagy hol oszthatod meg az ötleteid?

• Milyen konferenciák és fórumok elérhetőek APEX témában?

Előadó: Pataki Dávid, Enrol Consulting Kft.
Program:
17:30-18:00 gyülekezés
18:00-18:10 kahoot
18:10-19:00 előadás(ok)
19:00-19:30 Q&A, ismerkedés

Itt tudsz jelentkezni