Posts in category “Database”

VARCHAR2(4000 CHAR) Might Not Store 4000 Characters

VARCHAR2(4000) means 4000 bytes, not characters. Most people know this. What's less obvious: VARCHAR2(4000 CHAR) doesn't guarantee 4000 characters either.

Under the default MAX_STRING_SIZE=STANDARD, the hard column cap is 4000 bytes regardless of whether you declared BYTE or CHAR. In AL32UTF8, a Chinese character takes ~3 bytes, so VARCHAR2(4000 CHAR) on a column storing CJK text will fail once the actual byte count exceeds 4000 — around ~1333 characters in.

To actually store 4000 CJK characters in a single VARCHAR2, the instance needs MAX_STRING_SIZE=EXTENDED (12c+), which raises the limit to 32767 bytes. This is not the default — not even in 19c — and it's a one-way migration that requires running utl32k.sql in upgrade mode. Oracle keeps it off by default precisely because it changes data dictionary behavior and breaks compatibility.

Quick check for your instance:

SELECT value FROM v$parameter WHERE name = 'max_string_size';

STANDARD = 4000-byte ceiling. EXTENDED = 32767-byte ceiling.

Suppress SQLcl Banner and Version Noise with -S

When scripting with Oracle SQLcl, the startup banner (version, copyright, connection info) clamps your output. The -S (silent) flag suppresses all of it:

sql -S user/password@connect_string @script.sql

This gives you clean output suitable for piping or log capture.

For even more control inside the session, pair it with:

set heading off
set feedback off
set pagesize 0
set echo off

-S is the entry-level switch. The set commands handle the rest.

Useful Oracle SQL syntax features for column updates

  1. Multiple Column Updates using IN clause:
UPDATE table_name
SET (col1, col2, col3) = 
    (SELECT val1, val2, val3 FROM source_table WHERE condition)
WHERE condition;
  1. MERGE statement for conditional updates/inserts:
MERGE INTO target_table t
USING source_table s
ON (t.key = s.key)
WHEN MATCHED THEN
    UPDATE SET t.col1 = s.col1, t.col2 = s.col2
WHEN NOT MATCHED THEN
    INSERT (col1, col2) VALUES (s.col1, s.col2);
  1. Using DEFAULT values in updates:
UPDATE employees
SET (salary, commission) = (DEFAULT, DEFAULT)
WHERE department_id = 90;
  1. Updating with RETURNING clause to get modified values:
UPDATE employees
SET salary = salary * 1.1
WHERE department_id = 20
RETURNING employee_id, salary INTO :emp_id, :new_salary;
  1. Using row constructor expression:
UPDATE table_name
SET (col1, col2) = (SELECT * FROM (VALUES (val1, val2)));
  1. Conditional updates using CASE:
UPDATE employees
SET salary = CASE 
    WHEN department_id = 10 THEN salary * 1.1
    WHEN department_id = 20 THEN salary * 1.2
    ELSE salary
END;
  1. Using WITH clause (Common Table Expression) in updates:
WITH avg_sal AS (
    SELECT dept_id, AVG(salary) avg_salary
    FROM employees
    GROUP BY dept_id
)
UPDATE employees e
SET salary = (
    SELECT a.avg_salary 
    FROM avg_sal a 
    WHERE e.dept_id = a.dept_id
)
WHERE condition;

These syntaxes are particularly useful when:

  • You need to update multiple columns at once
  • The update values come from another table or subquery
  • You want to perform conditional updates
  • You need to track what was updated
  • You're dealing with complex data transformations

Remember that while these features provide more elegant solutions, it's important to:

  1. Test performance with your specific data volumes
  2. Ensure the business logic is clear to other developers
  3. Consider maintainability of the code
  4. Check if indexes are being used effectively

Navigating Oracle Foreign Key Constraint Deletion: A Developer's Comprehensive Guide

Understanding the "Child Record Found" Dilemma

As an Oracle database developer, you've likely encountered the frustrating ORA-02292: integrity constraint violated - child record found error. This message appears when you attempt to delete a record from a parent table that is still referenced by child records in another table.

What Causes This Error?

Referential integrity constraints prevent you from deleting records that are crucial to maintaining data relationships. While these constraints protect your data's consistency, they can also complicate deletion processes.

Systematic Troubleshooting Approach

Step 1: Identify the Constraint

When you encounter the error, note the specific constraint name. In our example:

ERROR at line 1:
ORA-02292: integrity constraint (ACME_CORP.FK_TRANSACTION_ACCOUNT) violated

Step 2: Locate Referencing Constraints

Use the following comprehensive query to find details about the problematic constraint:

SELECT a.table_name, 
       a.constraint_name, 
       a.r_constraint_name,
       b.column_name
FROM all_constraints a
JOIN all_cons_columns b ON a.constraint_name = b.constraint_name
WHERE a.r_constraint_name = 'FK_TRANSACTION_ACCOUNT';

Step 3: Investigate Child Records

Once you've identified the referencing table, query the specific records:

SELECT b.*
FROM HR.EMPLOYEE_BANK_ACCOUNTS a
JOIN ACME_CORP.FINANCIAL_TRANSACTIONS b 
ON b.employee_bank_account_id = a.account_id
WHERE a.account_id IN (
    -- Your deletion criteria here
);

Resolution Strategies

Option 1: Cascade Delete

If appropriate for your data model, use ON DELETE CASCADE:

ALTER TABLE ACME_CORP.FINANCIAL_TRANSACTIONS 
DROP CONSTRAINT FK_TRANSACTION_ACCOUNT;

ALTER TABLE ACME_CORP.FINANCIAL_TRANSACTIONS 
ADD CONSTRAINT FK_TRANSACTION_ACCOUNT 
FOREIGN KEY (employee_bank_account_id)
REFERENCES HR.EMPLOYEE_BANK_ACCOUNTS(account_id)
ON DELETE CASCADE;

Option 2: Selective Deletion

Manually delete or update child records before removing parent records:

-- First, delete or update child records
DELETE FROM ACME_CORP.FINANCIAL_TRANSACTIONS 
WHERE employee_bank_account_id IN (
    SELECT account_id 
    FROM HR.EMPLOYEE_BANK_ACCOUNTS 
    WHERE deletion_condition
);

-- Then delete parent records
DELETE FROM HR.EMPLOYEE_BANK_ACCOUNTS 
WHERE deletion_condition;

Best Practices

  1. Always use transactions to ensure data consistency

  2. Understand your data relationships before modifying constraints

  3. Test deletion scripts in a staging environment

  4. Consider soft delete strategies for complex data models

Understanding `COUNT`, `LAST`, `FIRST`, and `NEXT` in PL/SQL Collections

TL;DR

In PL/SQL, COUNT, LAST, FIRST, and NEXT are essential for handling collections, especially if there are gaps (unpopulated indexes). Here’s a quick summary:

  • COUNT: Gives the number of populated entries.
  • LAST and FIRST: Identify the highest and lowest populated indexes, respectively.
  • NEXT: Finds the next populated index, skipping gaps automatically—great for sparse collections.

In PL/SQL programming, collections like nested tables, VARRAYs, and associative arrays are powerful tools for handling sets of data. However, understanding how to work with populated and unpopulated indexes can be tricky. That’s where COUNT, LAST, FIRST, and NEXT methods come into play. These methods let you manage and iterate over collections effectively, especially when dealing with gaps (unpopulated indexes). Let’s look at each one and how to use it.

1. COUNT

  • Purpose: Returns the number of populated elements in a collection.
  • Use Case: COUNT is useful when you need the exact count of entries in a collection, especially for fully populated collections without gaps.

Example:

DECLARE
  TYPE NumberTable IS TABLE OF NUMBER;
  v_numbers NumberTable := NumberTable(1, 2, 3, 4, 5); -- Fully populated
BEGIN
  DBMS_OUTPUT.PUT_LINE('COUNT: ' || v_numbers.COUNT);  -- Outputs: 5
END;

2. LAST

  • Purpose: Returns the highest populated index in the collection, whether all indexes are filled or not.
  • Use Case: When you need to find the highest valid index, such as for looping through all possible entries.

Example:

DECLARE
  TYPE NumberTable IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  v_numbers NumberTable;
BEGIN
  v_numbers(1) := 10;
  v_numbers(3) := 30; -- Gap at index 2
  v_numbers(5) := 50;

  DBMS_OUTPUT.PUT_LINE('LAST: ' || v_numbers.LAST);  -- Outputs: 5
END;

3. FIRST

  • Purpose: Returns the lowest populated index in the collection.
  • Use Case: Similar to LAST, FIRST is used when you want to start iterating from the lowest populated index.

Example:

DECLARE
  TYPE NumberTable IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  v_numbers NumberTable;
BEGIN
  v_numbers(2) := 20;
  v_numbers(4) := 40;

  DBMS_OUTPUT.PUT_LINE('FIRST: ' || v_numbers.FIRST);  -- Outputs: 2
END;

4. NEXT

  • Purpose: Given an index, NEXT returns the next highest populated index. If there are no more populated indexes after the current one, it returns NULL.
  • Use Case: NEXT is perfect for iterating only over populated elements, skipping gaps automatically.

Example:

DECLARE
  TYPE NumberTable IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  v_numbers NumberTable;
  v_index PLS_INTEGER;
BEGIN
  v_numbers(1) := 10;
  v_numbers(3) := 30;
  v_numbers(5) := 50;

  v_index := v_numbers.FIRST;
  WHILE v_index IS NOT NULL LOOP
    DBMS_OUTPUT.PUT_LINE('Value at index ' || v_index || ': ' || v_numbers(v_index));
    v_index := v_numbers.NEXT(v_index);
  END LOOP;
END;

Output:

Value at index 1: 10
Value at index 3: 30
Value at index 5: 50

Choosing the Right Method

  • COUNT is ideal for knowing how many elements are populated.
  • LAST and FIRST are great for determining the range of populated indexes.
  • NEXT is best when you want to loop through only populated elements, especially if there are gaps.

Key Takeaways

Using COUNT, LAST, FIRST, and NEXT effectively allows you to handle PL/SQL collections with gaps, optimize loops, and avoid errors when accessing unpopulated indexes. For sparse collections (with gaps), FIRST and NEXT are preferred over looping with 1..LAST to ensure you only interact with valid, populated indexes.

Best Practice for Gapped Collections

When working with collections that might have gaps, avoid using 1..COUNT or 1..LAST directly in loops, as they may access unpopulated indexes and cause errors. Instead:

  1. Use FIRST and NEXT to loop through only populated elements:

    • Start with v_index := v_collection.FIRST and use v_index := v_collection.NEXT(v_index) to move to the next populated index.
    • This skips gaps automatically, making it the most efficient way to handle sparse collections.
  2. Add NULL Checks if Necessary:

    • Even with FIRST and NEXT, you can add an IF condition to verify a non-null value for specific fields if you expect incomplete records.

Example:

DECLARE
  TYPE MyCollection IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  v_collection MyCollection;
  v_index PLS_INTEGER;
BEGIN
  v_collection(1) := 10;
  v_collection(3) := 30;
  v_collection(7) := 70;

  v_index := v_collection.FIRST;
  WHILE v_index IS NOT NULL LOOP
    DBMS_OUTPUT.PUT_LINE('Value at index ' || v_index || ': ' || v_collection(v_index));
    v_index := v_collection.NEXT(v_index);
  END LOOP;
END;

This approach ensures your code only processes valid elements, skipping over unpopulated entries smoothly.