Guilherme G.

Hi MotherDuck team, I'm hitting an issue where every DDL operation on my account fails with a stale internal database UUID, even from your web SQL editor. Account email: ggnicolau@gmail.com What happened: I had two databases on my account: `my_db` (the auto-created default) and `lakehouse` (where my actual project lives). The `my_db` only contained one legacy table from an old migration. To clean up, I dropped `my_db` entirely via `DROP DATABASE my_db`. I also dropped the empty `main` schema on `lakehouse` since it was unused. Both DROPs succeeded without warnings. The problem: Now any DDL operation — including in your own web SQL editor — fails with: Catalog Error: SET schema: No catalog + schema named "MD_DB_F881621A_70D7_4EBB_8910_730AEF2F3633.main" found. That UUID (MD_DB_F881621A_70D7_4EBB_8910_730AEF2F3633) is the internal ID of the original `my_db` I dropped. The account's default database pointer still references that UUID even though the database no longer exists. What still works: - SELECT queries against existing tables in `lakehouse.raw.*`, `lakehouse.bronze.*`, etc. — bypass the SET schema init - SHOW DATABASES, REFRESH DATABASES, basic introspection What does NOT work: - CREATE SCHEMA (any database, any name) - CREATE TABLE (suspect — haven't tested yet) - Any operation that triggers the implicit `SET schema` during session init Reproduction: 1. Open https://app.motherduck.com → SQL editor 2. Run: `CREATE SCHEMA IF NOT EXISTS lakehouse.main;` 3. Error appears as above What I tried: - Recreated `my_db` via `CREATE DATABASE my_db`. The new `my_db` got a fresh UUID, but the default pointer still references the old UUID. SELECT operations started working after this, but DDL still fails. - `REFRESH DATABASES;` — no effect on the stale pointer. - Tried connecting from local DuckDB Python client with various connection strings (`md:`, `md:lakehouse`, ATTACH with alias) — same error since it's server-side. What I need: Please reset the default database pointer for my account to point to a valid database. `lakehouse` is the one I actively use and would be a fine new default. Alternatively, point it to the newly-recreated `my_db` if that's simpler. Context for the broader picture (if useful for your team's bug triage): The fact that `DROP DATABASE` succeeded silently on the account's default database without either (a) refusing the operation or (b) updating the default pointer to another database feels like a footgun. A future check on `DROP DATABASE` that warns/refuses when the target is the account default would prevent others from hitting this. Happy to provide additional diagnostics if needed. Thanks for the help. Best, Guilherme Nicolau ggnicolau@gmail.com