How do I fix ORA-32795?

Declare the column BY DEFAULT instead of ALWAYS. It still generates values when you omit the column, and accepts yours when you supply them. If the table is already loaded, move the sequence past the imported IDs so the next generated value cannot collide. For a one-off load into a table you cannot alter, drop the identity, load, then add it back as BY DEFAULT.

Oracle · error reference

ORA-32795: cannot insert into a generated always as identity column

ORA-32795: cannot insert into a generated always as identity column

Oracle refuses explicit values for a GENERATED ALWAYS AS IDENTITY column. Why it breaks every data load that carries its own primary keys, and the one-word change that fixes it.

What the database is telling you

An identity column declared GENERATED ALWAYS is owned by Oracle. The sequence behind it produces every value, and an INSERT that supplies one of its own is rejected outright — not coerced, not ignored. This is the whole difference between ALWAYS and BY DEFAULT, and it is the whole error.

Why it shows up in a migration

A migration is exactly the case where you must supply your own IDs. The rows already exist with primary keys, and other tables reference those keys by value. If the target regenerates them, every foreign key in the database points at the wrong row — so a converter that emits GENERATED ALWAYS produces a schema that cannot accept the data it was built for. The failure is immediate and total: the first INSERT into the first table dies.

Common causes

A MySQL AUTO_INCREMENT or Postgres SERIAL column converted to Oracle as GENERATED ALWAYS AS IDENTITY.
Hand-written Oracle DDL that used ALWAYS because it reads as the stricter, safer option.
An INSERT that names the identity column explicitly, even when passing NULL.

How to fix it

1
Declare the column BY DEFAULT instead of ALWAYS. It still generates values when you omit the column, and accepts yours when you supply them.
```
ALTER TABLE orders MODIFY (id GENERATED BY DEFAULT AS IDENTITY);
```
2
If the table is already loaded, move the sequence past the imported IDs so the next generated value cannot collide.
```
ALTER TABLE orders MODIFY (id GENERATED BY DEFAULT AS IDENTITY (START WITH LIMIT VALUE));
```
3
For a one-off load into a table you cannot alter, drop the identity, load, then add it back as BY DEFAULT.

What DBShifts does about it

DBShifts emits GENERATED BY DEFAULT AS IDENTITY for every auto-increment column converted to Oracle, precisely so the bulk transfer can carry the source's own IDs across. The choice is deliberate and commented in the DDL generator — ALWAYS would produce a schema that rejects its own data.

Oracle DDL generator

Migrating between engines?

DBShifts converts the schema, moves the data, and then proves the two sides match with a type-aware checksum per table — not just a row count. Errors like this one are handled on the way, and the ones that cannot be handled are reported rather than logged and forgotten.

Start free See the migration paths

Related errors

Oracle

ORA-03076: unexpected item DEFAULT in a CREATE TABLE

Oracle wants DEFAULT before NOT NULL. MySQL accepts either order, so converted DDL fails on clause order alone — with an error that never mentions order.

Oracle

ORA-01790 on a multi-row MERGE with bind variables

Oracle cannot infer a type for a bind variable inside a UNION ALL branch, so a batched MERGE fails on values that all look identical. Why batching causes it and single rows do not.

← All database errors