I am working on a update script to my Oracle Schema and during my testing I drop my schema and re-import a clean copy. But I leave open a package file.pkb I am updating in my script. When I reconnect and go back to toad for the same edit tab, I get the following, can i turn this off? I can hit cancel, then when i hit f9, it comes back.
Hi Marc,
Unfortunately, there's no current way to simply turn this dialog off, but there may be a couple of workarounds.
First, if you're working within a test schema, and it's being dropped and recreated multiple times via a script, that's probably a schema you wouldn't want to track within Team Coding. In that scenario, team-based change management wouldn't make much sense (since you're essentially using the schema in single-user mode by completely dropping and recreating the schema as needed) and revision history tracking wouldn't make much sense since the schema's being completely dropped and recreated from scratch. I would probably recommend using Team Coding to manage your development schema changes and leave the testing (QA/UAT) schemas off of Team Coding's management list. Of course, you can always add it after you've finished your update script.
Alternatively, you can temporarily deactivate Team Coding's management of that specific Team Project or database schema until after the work on your script is finished. Once your script is finished, you can re-enable the Team Project or schema in Team Coding's configuration page. This would allow you to create revision snapshots of the QA environment after your script is finished and has successfully created your new database schema environment.
Alternatively, you can also keep your object DDL as a plain DDL script in another editor tab or external editor (as opposed to opening the object directly within Toad). When you open a database object in Toad, the editor tab is tied to that object and Team Coding monitors the underlying database object for changes by anyone else. By just copying it as a generic DDL script, the editor will see its source as a script until it's compiled, rather than as an object in the database.
The purpose of this dialog is to handle situations where one user opens an object in Toad, but before they have a chance to compile their changes, a second user opens the same object, makes a change, and compiles it into the database (perhaps using an external tool such as SQL*Plus). This allows Toad to recognize that the database source was recently changed since it was opened or checked out so that you don't accidentally overwrite someone else's changes.
We can look into providing a user option to disable this check; but in the meantime, I hope this information helps provide a couple of workaround solutions. Please feel free to let us know if you have any other questions or if there's anything else we can do.
Thanks,
-John
