We use the DEV-TEST-PRODUCTION schema. The developers can use any tool on
DEV instances and test their code on TEST environment.
They *don't* have access to PROD instances.
Usually works fine :O)
Cheers, Dimitre Radoulov
Toad w/ DBA module or who have access to generic schemas that contain important data == bad.
Regular Toad with individual developer accounts, no insert/update/delete access on important tables, roles, role-level security and limits on the autoextend feature for specific tablespaces == good practice.
my one big complaint about toad: by default it comes with "autocommit off" ... which is fine, but it means every session opened to a schema in the database has an implicit "begin transaction" attached to it, so you've got lots of uncommitted/open transactions ... which can block processes from time to time.
Sounds like you've got a very unorganized dev environment going on ... your
problem isn't the use of Toad, its the lack of a properly configured
workspace for your programmers.
todd
Hi all,
My developers (who currently just use SQL Plus) now are wanting to use
Quest TOAD. From what I've used it in the past, it is far too powerful for
developers. (I don't trust my developers with creating tablespaces, etc.).
Plus, I've found that TOAD is far too easy to delete objects, etc.
Any recommendations, etc would greatly be appreciated!
-Fred S.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-- //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
