The problem is that the dynamic SQL statement runs in its own separate execution context - statements executed in that context will be affected by the USE command, but the execution context of the dynamic SQL statement will not affect the execution context of the batch that prepared and submitted the dynamic SQL for execution.

With one exception, our DEV environments use the exact same schema as our PROD environments (and the QA and UAT environments in between) - same DB and object names for everything. That way, we don't have to change any code when it migrates from environment to environment. In that one environment (for which I am currently developing some processes, unfortunately), an important database is named differently in DEV than in PROD, so all three-part qualified object names and any USE statements involved must be changed when the code migrates - an enormous hassle and potential source of deployment problems.

If possible, you should change the database names to be consistent from environment to environment - one schema change will be less painful over the long run than making all the changes every time you deploy new code to PROD.