I would love the option to have a TOAD table that contains formatter config in it. All of our database developers have our own Formatter file and folks don't like to change what they don't understand. This messes up the ability to show differences between revisions in source control if everyone is using different rules. If I could centralize toad settings like that it would keep us on the same basic page.
1 Like
Hi Keith,
That's not a bad idea. Would this work just as well?
- put a copy of fmtPlus.opt in some central location
- have everyone run a batch file to start Toad - which would contain something like this:
xcopy path_to_central_location\FmtPlus.opt "%APPDATA%\Quest Software\Toad for Oracle\16.3\User Files\"
"%ProgramFiles%\Quest Software\Toad for Oracle 16.3\Toad.exe"
That is the direction I am heading right now, but it is a touch more management overhead that I am hoping a shared schema would resolve naturally. I have always wanted a comprehensive TOAD schema config place that I could go to setup all of those objects like the explain plan table, the tablespace pieces all at one time. Even possibly shared settings options one day.
To me this is more of a wish list item.
So are you thinking that the settings would reside on some central repository, not necessarily the database that you are logging into with Toad?
I am implementing now from a central repository and copying the file like you suggested however I would prefer them to be in the toad schema on the logged in instance
Sorry, I think I wasn't clear.
In that last comment, when I said "central repository" I meant a database. I was just trying to differentiate between the DB you are logging into (in which case, each DB would need its own table with formatter settings) vs some DB that Toad checks for settings regardless of where you log in.
That is a good point I could see a case for a central repository as well as a toad schema option. For us I would probably opt for a central database option if it was available. We run multi-tenet in our development and test environments so even simple things like having a common toad explain plan table that all toad clients could use no matter which PDB we were connected to would be handy.
If we add this feature, maybe a central database should be the only option. I mean, local file could still be an option, but not allowing the table to be in just "whatever DB I happen to log into".
If we had an option to keep formatter settings in whatever DB you were logged into, and you had a couple of connections open to different databases, some with the formatter options table and some without (or with different format options in each table), we'd have to reload formatter options as you switch from one connection to another. That seems like a problem (or at least confusion) waiting to happen.
I can agree with that. A wish list item to be sure but it would be nice to centralize a lot of those types of things.
1 Like