Closed lowlydba closed 3 years ago
Switching database contexts is not a supported scenario in the underlying framework - DbUp. It never supported crossing the boundaries of a single database and the SchemaVersions table cannot be addressed in a three part naming manner in its current implementation. As described here, the best solution seems to be to have independent deployment scenarios for each database, rather than switching DB contexts.
Ack! That is frustrating. Our use case involves making a change to the database itself, so generally switching out to a system database. I'd rather not have to keep a separate migration workflow for "master" database migrations that are actually changes for user databases.
Thanks for the quick response! I'll see if I can't come up with a workaround.
I'll close this issue for now, but please, share the workaround if you find one!
When running a migration script, if the script changes database context, but does not return to the original database context, the migrate function will error out from being unable to find the SchemaVersionTable:
Not sure the best approach - three part naming for the logging table? Open a new connection for the logging portion? I might be able to work on a PR for this depending on what approach is deemed desirable...