> ## Documentation Index
> Fetch the complete documentation index at: https://planetscale.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Constraint not found
> A deploy fails because it drops a CHECK or FOREIGN KEY constraint by a name the production table no longer has.
export const PlatformAvailability = ({current, vitess, postgres, neki}) => {
const docsHref = path => {
if (!path) return path;
const normalized = path.startsWith('/') ? path : `/${path}`;
return normalized;
};
const labels = {
vitess: 'Vitess',
postgres: 'Postgres',
neki: 'Neki'
};
const combinedLabels = {
both: 'Vitess and Postgres',
all: 'Vitess, Neki, and Postgres',
'postgres-neki': 'Postgres and Neki'
};
if (combinedLabels[current]) {
return
{combinedLabels[current]}
;
}
const hasVitess = current === 'vitess' || Boolean(vitess);
const hasPostgres = current === 'postgres' || Boolean(postgres);
const hasNeki = current === 'neki' || Boolean(neki);
const only = [hasVitess, hasPostgres, hasNeki].filter(Boolean).length === 1;
const engines = [];
if (current === 'vitess' || current === 'postgres' || current === 'neki') engines.push(current);
if (hasVitess && current !== 'vitess') engines.push('vitess');
if (hasNeki && current !== 'neki') engines.push('neki');
if (hasPostgres && current !== 'postgres') engines.push('postgres');
return
;
};
A deploy request can fail before copying starts because it drops a constraint by a name that does not exist on the production table:
```text theme={null}
Found DROP CONSTRAINT: DROP CHECK `orders_amount_chk`, but could not find constraint name in map
```
MySQL requires `CHECK` and `FOREIGN KEY` constraint names to be unique across the whole schema. Because an online schema change builds a copy of the table alongside the original, PlanetScale gives every constraint on the copy a new name: the original name plus a generated suffix such as `orders_amount_chk_5vtaqz7kepok6wa91vryrkrje`. The suffix changes every time the table goes through a deploy. See [Foreign key constraint names change on every deployment](/docs/vitess/foreign-key-constraints#foreign-key-constraint-names-change-on-every-deployment).
When the deploy runs, the `DROP` must name the constraint exactly as it exists on the production table at that moment. If the table was deployed again after this deploy request's changes were computed, or the name recorded for the production branch is out of date, the names no longer match and the deploy stops.
## How to fix it
Check the current name on the production branch:
```sql theme={null}
SHOW CREATE TABLE orders\G
```
Then open a new deploy request:
Close or cancel the failed deploy request.
Create a fresh branch from the production branch so it picks up the current constraint names.
Apply your schema change on the new branch and open a new deploy request.
If the new deploy request fails with the same error, contact support with the deploy request number.
## Need help?
Get help from [the PlanetScale Support team](https://planetscale.com/contact?initial=support), or join our [Discord community](https://pscale.link/community) to see how others are using PlanetScale.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.