SQLite UPDATE: WHERE, mehrere Spalten & UPDATE FROM

UPDATE ändert vorhandene Zeilen

Während INSERT neue Zeilen anlegt, ändert UPDATE Zeilen, die bereits in der Tabelle stehen. Die SQLite-UPDATE-Syntax ist kurz und lohnt sich auswendig zu lernen:

UPDATE table_name
SET column = value
WHERE condition;

Ein praxisnahes Beispiel:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT,
    status TEXT DEFAULT 'active'
);

INSERT INTO users (name, email) VALUES
    ('Ada', 'ada@old.com'),
    ('Boris', 'boris@old.com'),
    ('Rosa', 'rosa@old.com');

UPDATE users
SET email = 'ada@new.com'
WHERE id = 1;

SELECT * FROM users;

SET legt fest, was sich ändert. WHERE legt fest, welche Zeilen betroffen sind. Alles andere in der Tabelle bleibt unangetastet.

Warum die WHERE-Klausel in der Praxis Pflicht ist

Rein technisch ist WHERE optional. In der Praxis ist das Weglassen aber der schnellste Weg, sich als Junior-Entwickler den Nachmittag zu ruinieren:

UPDATE users SET status = 'inactive';
-- jeder einzelne Benutzer ist jetzt inaktiv

Ohne Filter trifft die Bedingung auf jede Zeile zu. SQLite zieht das klaglos durch. Schreib darum immer zuerst das WHERE und danach erst das SET – allein diese Angewohnheit erspart dir jede Menge Ärger.

Wenn du dir bei deinem WHERE nicht sicher bist, prüf die Bedingung vorher mit einem SELECT:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, status TEXT);
INSERT INTO users VALUES (1, 'Ada', 'active'), (2, 'Boris', 'active'), (3, 'Rosa', 'pending');

-- Vorschau, welche Zeilen betroffen wären.
SELECT id, name, status FROM users WHERE status = 'pending';

-- Dann das UPDATE mit demselben WHERE ausführen.
UPDATE users SET status = 'active' WHERE status = 'pending';

SELECT * FROM users;

Gleiche Bedingung, zwei Statements. Das SELECT ist dein Trockenlauf.

SQLite Update mehrere Spalten gleichzeitig

Trenne die Zuweisungen einfach per Komma innerhalb eines einzigen SET. Ein SET, viele Spalten:

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL,
    stock INTEGER
);

INSERT INTO products VALUES (1, 'Widget', 9.99, 100);

UPDATE products
SET price = 12.99,
    stock = 75,
    name = 'Premium Widget'
WHERE id = 1;

SELECT * FROM products;

Eine einzige Runde zur Datenbank, eine Zeile geändert, drei Spalten aktualisiert. Schreib keine drei einzelnen UPDATE-Statements, wenn eines reicht.

Ausdrücke rechts vom =

Der Wert hinter = muss kein Literal sein. Es kann jeder beliebige Ausdruck stehen — auch einer, der auf den aktuellen Wert der Spalte zugreift:

CREATE TABLE products (id INTEGER PRIMARY KEY, name TEXT, price REAL, stock INTEGER);
INSERT INTO products VALUES
    (1, 'Widget', 10.00, 50),
    (2, 'Gadget', 20.00, 30),
    (3, 'Gizmo', 15.00, 80);

-- Preise um 10 % erhöhen.
UPDATE products
SET price = price * 1.10;

-- Bestand für eine Zeile verringern.
UPDATE products
SET stock = stock - 1
WHERE id = 2;

SELECT * FROM products;

price * 1.10 liest den aktuellen Preis aus, multipliziert ihn und schreibt das Ergebnis zurück. Bei der rechten Seite greift SQLite auf die aktuellen Werte der Zeile zu, bevor irgendeine Zuweisung dieses Statements wirksam wird – du kannst also problemlos mehrere Spalten gleichzeitig referenzieren:

UPDATE products SET price = price * 1.10, stock = stock + price;
-- 'price' auf der rechten Seite ist hier der ALTE Preis, nicht der gerade aktualisierte.

UPDATE ... FROM: Werte aus einer anderen Tabelle übernehmen

Seit SQLite 3.33 unterstützt UPDATE eine FROM-Klausel für tabellenübergreifende Updates. Das ist die sauberste Variante, um Daten zwischen Tabellen abzugleichen – quasi das SQLite-Pendant zu einem UPDATE JOIN:

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, total_spent REAL DEFAULT 0);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, amount REAL);

INSERT INTO customers (name) VALUES ('Ada'), ('Boris'), ('Rosa');
INSERT INTO orders (customer_id, amount) VALUES
    (1, 50.00), (1, 30.00),
    (2, 100.00),
    (3, 25.00), (3, 75.00);

UPDATE customers
SET total_spent = totals.sum_amount
FROM (
    SELECT customer_id, SUM(amount) AS sum_amount
    FROM orders
    GROUP BY customer_id
) AS totals
WHERE customers.id = totals.customer_id;

SELECT * FROM customers;

Die Subquery berechnet die Summen pro Kunde, und das äußere UPDATE führt diese Ergebnisse über id wieder mit customers zusammen. Ohne UPDATE ... FROM müsstest du für jede Spalte eine korrelierte Subquery schreiben – das wird schnell unübersichtlich.

Ein paar Regeln, die du im Hinterkopf behalten solltest:

• Die Zieltabelle steht nach UPDATE, nicht in der FROM-Liste.
• Der Join passiert in der WHERE-Klausel – ein ON-Schlüsselwort gibt es hier nicht.
• Falls der Join mehr als eine Zeile im FROM treffen könnte, ist das Ergebnis nicht definiert. Sorge dafür, dass deine Join-Schlüssel höchstens einen Treffer pro Zielzeile liefern.

SQLite UPDATE RETURNING: Geänderte Zeilen direkt zurückgeben

Ab SQLite 3.35 kann UPDATE die geänderten Zeilen direkt im selben Statement zurückgeben. Praktisch, wenn deine Anwendung die aktualisierten Werte braucht, ohne danach noch ein SELECT abzusetzen:

CREATE TABLE products (id INTEGER PRIMARY KEY, name TEXT, price REAL);
INSERT INTO products VALUES (1, 'Widget', 10.00), (2, 'Gadget', 20.00);

UPDATE products
SET price = price * 0.9
WHERE price > 15
RETURNING id, name, price;

Du bekommst die tatsächlich geänderten Zeilen samt ihrer neuen Werte zurück. Das spart einen zusätzlichen Roundtrip und beseitigt eine ganze Klasse von Race Conditions in nebenläufigem Code. Später in diesem Kapitel gibt es eine eigene Seite zu RETURNING.

UPDATE OR REPLACE: Konflikte mit Constraints abfangen

Verletzt dein UPDATE einen UNIQUE-Constraint, bricht SQLite das Statement standardmäßig mit einem Fehler ab. Über die OR-Klausel kannst du stattdessen eine andere Strategie festlegen:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT UNIQUE,
    name TEXT
);

INSERT INTO users VALUES
    (1, 'ada@x.com', 'Ada'),
    (2, 'boris@x.com', 'Boris');

-- Dies würde mit einer UNIQUE-Constraint-Verletzung fehlschlagen:
-- UPDATE users SET email = 'boris@x.com' WHERE id = 1;

-- OR REPLACE löscht die kollidierende Zeile und führt dann das Update aus.
UPDATE OR REPLACE users
SET email = 'boris@x.com'
WHERE id = 1;

SELECT * FROM users;

Die Optionen sind OR ABORT (Standard), OR REPLACE, OR IGNORE, OR FAIL und OR ROLLBACK. Heikel ist vor allem REPLACE – die Variante löscht nämlich die kollidierende Zeile, was sich über Foreign Keys auch noch weiter durchziehen kann. Greif nur dann dazu, wenn du wirklich sagen willst: „Falls es schon eine Zeile mit diesem eindeutigen Wert gibt, weg damit."

Für klassisches Upsert-Verhalten ist die spezielle Syntax INSERT ... ON CONFLICT deutlich übersichtlicher. Dazu gibt es eine eigene Seite.

Riskante Updates in eine Transaktion packen

Wenn du viele Zeilen änderst oder mehrere UPDATE-Anweisungen ausführst, die nur gemeinsam Sinn ergeben, solltest du sie in eine Transaktion einschließen. Geht irgendwo etwas schief, kannst du den Zustand davor per Rollback wiederherstellen:

CREATE TABLE accounts (id INTEGER PRIMARY KEY, name TEXT, balance REAL);
INSERT INTO accounts VALUES (1, 'Ada', 100.00), (2, 'Boris', 50.00);

BEGIN;
    UPDATE accounts SET balance = balance - 25 WHERE id = 1;
    UPDATE accounts SET balance = balance + 25 WHERE id = 2;
COMMIT;

SELECT * FROM accounts;

Schlägt die zweite Anweisung fehl (etwa weil ein Constraint zuschlägt), macht ROLLBACK die erste rückgängig. Ohne Transaktion bliebe ein halber Transfer übrig — Ada hat 25 weniger, Boris steht unverändert da. Transaktionen bekommen später ihr eigenes Kapitel; vorerst reicht es zu wissen, dass es sie gibt und dass größere Updates fast immer in eine Transaktion gehören.

Typische Stolperfallen

Eine kurze Liste der Klassiker, über die viele stolpern:

• WHERE vergessen — dann wird jede Zeile aktualisiert. Sprich dein Statement einmal laut durch, bevor du es ausführst.
• Falscher Operator im WHERE — WHERE status = NULL trifft auf nichts zu. Richtig ist IS NULL. Mehr dazu auf der Seite zu den Operatoren.
• Update mit einer Subquery, die mehr als eine Zeile liefert, obwohl du genau eine erwartest. Setze LIMIT 1 ein oder aggregiere die Subquery — sonst gibt es Fehler oder unerwartete Ergebnisse.
• UPDATE OR REPLACE mit UPSERT verwechseln. OR REPLACE löscht die kollidierenden Zeilen. INSERT ... ON CONFLICT DO UPDATE ändert sie an Ort und Stelle. Zwei verschiedene Operationen.

Als Nächstes: DELETE

UPDATE ändert Zeilen, DELETE entfernt sie. Dieselbe Disziplin beim WHERE gilt auch hier — und dieselbe Gewohnheit, vorher ein SELECT laufen zu lassen, bewahrt dich vor denselben Katastrophen. Das ist Thema der nächsten Seite.