SQL SQLWARNING

What is SQLWARNING in SQL?

SQLWARNING is a predefined condition that matches any SQLSTATE whose class is '01', allowing stored programs to catch or signal all warning-level conditions.

Welcome to the Galaxy, Guardian!
You'll be receiving a confirmation email

Follow us on twitter :)

Oops! Something went wrong while submitting the form.

Compatible dialects for SQL SQLWARNING:

SQL SQLWARNING Full Explanation

SQLWARNING is part of the SQL/PSM (Persistent Stored Modules) condition-handling framework. The SQL standard classifies every execution condition with a five-character SQLSTATE. Class '01' is reserved for warnings (for example '01000' – general warning, '01003' – null value eliminated). By referring to SQLWARNING inside a DECLARE HANDLER, SIGNAL, or RESIGNAL statement you can treat every warning uniformly without listing each individual SQLSTATE.When the database issues any warning during the execution of a stored procedure, function, trigger, or compound statement, control transfers to the matching SQLWARNING handler (CONTINUE, EXIT, or UNDO). Inside the handler you can log, raise a different error, correct data, or ignore the problem. You can also raise a warning manually with SIGNAL SQLWARNING, letting the caller know something is not fatal but worth attention.Because warnings do not roll back transactions automatically, it is up to the developer to decide whether to continue or abort after catching SQLWARNING. Always check the diagnostics area (GET DIAGNOSTICS) for additional detail such as MESSAGE_TEXT, COLUMN_NUMBER, and CONSTRAINT_NAME.

SQL SQLWARNING Syntax

-- Declare a handler that runs on any warning
DECLARE CONTINUE HANDLER FOR SQLWARNING
   SET @had_warning = TRUE;

-- Manually raise a generic warning
SIGNAL SQLWARNING
   SET MESSAGE_TEXT = 'Price rounded to two decimals';

SQL SQLWARNING Parameters

Example Queries Using SQL SQLWARNING

-- Example 1: Ignore all warnings during data load but flag them
CREATE PROCEDURE bulk_insert()
BEGIN
   DECLARE CONTINUE HANDLER FOR SQLWARNING SET @warn = TRUE;
   INSERT INTO products_tmp SELECT * FROM staging_products;
   IF @warn THEN
      CALL log_warning('Warnings occurred while loading products');
   END IF;
END;

-- Example 2: Promote a warning to an error
CREATE PROCEDURE update_price(p_id INT, p_price DECIMAL(10,2))
BEGIN
   DECLARE EXIT HANDLER FOR SQLWARNING
      SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid price update';
   UPDATE products SET price = p_price WHERE id = p_id;
END;

Expected Output Using SQL SQLWARNING

Example 1 completes the INSERT even if the server emits warnings (e
g
, truncation)
Variable @warn becomes TRUE so the procedure can log the event
Example 2 turns any warning raised during UPDATE (such as out-of-range value) into an error with SQLSTATE '45000', causing the caller to receive an exception

Use Cases with SQL SQLWARNING

Capture all truncation, overflow, or data-conversion warnings during batch loads
Convert benign warnings into logged audit records
Promote specific operations to errors when any warning occurs, enforcing stricter data quality
Raise custom warnings from business logic without aborting the transaction

Common Mistakes with SQL SQLWARNING

Assuming SQLWARNING rolls back a transaction; warnings do not perform automatic rollback
Forgetting CONTINUE vs EXIT, which changes whether execution resumes after the handler
Confusing SQLWARNING (class '01') with SQLEXCEPTION (classes other than '00', '01', '02')
Using SQLWARNING outside compound statements or stored routines where handlers are permitted

First Introduced In

SQL:1999 (SQL/PSM)

Frequently Asked Questions

What is the purpose of SQLWARNING?

SQLWARNING groups all SQLSTATE class '01' conditions so you can catch or raise every warning with a single keyword.

How do I choose between CONTINUE and EXIT handlers for SQLWARNING?

Use CONTINUE to resume execution after the handler, typically for logging. Use EXIT to abandon the compound statement, effectively treating warnings as errors.

Are warnings ever fatal?

By default, warnings are non-fatal. You can make them fatal by re-signalling an error inside the SQLWARNING handler or setting strict SQL modes (for example in MySQL).

Can I test for specific warnings instead of all of them?

Yes. Declare additional handlers for exact SQLSTATE values such as '01003' before the generic SQLWARNING handler. The first match in declaration order is used.