database - TOra
Description: TOra

Next: additionalhelp, Previous: editor, Up: preferences

#### 3.8.3 Database Settings

This page of the options contains settings on how to interact with the database.

Autocommit changes
  If this is set any changes made to the database will be automatically committed as soon as you make them. Use this with care, the transaction handling is there for a reason you know.
Reading object cache
  There are four options of object cache behaviour. Start read object cache when needed - will start reading it when it is first used. Read object cache on connect - TOra will start reading the object cache when you start a connection to a database. Never read object cache until mandatory - TODO. Never read object cache until mandatory (Will leave some parts of application nonfunctional - TODO. Note that reading this is quite a costly query so you probably shouldn't have this checked if you are in a production environment, on a slow connection or not using the object cache. The object cache is mostly used for describing tables, the PL/SQL debugger and code completion.
Initial rows to fetch in query
  This setting indicates how many rows to always fetch from a query when executing it. Observe that you can always read more from the individual query just by scrolling down. Check the All checkbox to always read all available records. Be aware that TOra will interact sluggishly or not at all while reading many lines. It will also keep the entire result in memory so checking the All box and reading a really large table could bring your machine to it's knees.
Initially read in content editor
  If set to something other than All a query will be placed only this number of rows initially from Oracle when browsing the content. The reason for this is that Oracle will be under high load if a content list is started on a large table. When this value is reached the query will be reread to fetch the rest of the values so you as a user will not see any difference.
Maximum size display
  The maximum width a list column will get automatically regardless of how large the content is. This is so you can still see the rest of the columns even if one of the first can contain very large values. You can always resize the column by hand afterwards.
Firewall mode.
  Makes each connection in connection pool to run extra queries (selecting sysdate from dual) at specified interval (see "Connection test interval" option). This could be useful if there is a firewall between TOra and database and firewall is dropping connections if there is no traffic.

  Note! If you change this option, you have to reconnect in order to make it effective.

Connection test interval
  Interval in seconds at which TOra should be sending dummy queries to database (see "Firewall mode").
Indicate empty values as ”.
  Display NULL values as "{null}" in the specified color.
Number format.
  Select the format for displaying numbers. You can choose from "Default", "Scientific" and "Fixed decimal" where the last allows you to specify the number of decimals.

There may also be pages under this for each individual database provider. Currently only Oracle and MySql uses this feature. That setup looks like this.

Checkpoint name
  This is a checkpoint TOra should use when it is making changes that need to be rolled back. One place where this is used is to perform explain plans without filling up the plan table. The name doesn't matter, just make sure you don't use this checkpoint name yourself.
Default date format
  The format that you prefer dates to be displayed. Changing this will require a reconnect to the database before it starts to operate. The string should be a standard Oracle date to string conversion specification. For more information see the Oracle SQL Reference.
Maximum cursors to keep open
  This specifies the size of the connection pool if TOra was compiled with OTL_STREAM_POOLING_ON.
Max LONG and LOB data length
  The amount of data to read from LONG, BLOB or CLOB data fields. If you always want all the data to be read check the Unlimited checkbox to the right. LONG datafields can not be specified as Unlimited, if this is specified 33000 characters are read by default.
Explain plan table
  The table to use to temporarily store explained execution plans. the table can be specified with or without a schema name. If you leave out a schemaname the table will be created in the schema of the connected user, either manually by clicking Create Table button or automatically by TOra if needed and confirmed by the user.
Keep plans
  If this is checked explained plans are left in the explain plan table. The normal behaviour is to rollback the explanation after it is initially read to keep the explain plan table from filling up with old plans.
Use V$SQL_PLAN
  If possible, TOra will try to get the execution plan by reading V$SQL_PLAN instead of executing EXPLAIN for the statement.
shared PLAN_TABLE
  Enable this option if you wish to use the system-wide PLAN_TABLE provided by Oracle or a shared plan table set up by yourself. In this case TOra will never create a plan table for you.
Extractor options
  These options control the way TOra generates object creation scripts (ddl's) in database extractor tool as well as "Script" tab in schema browser.
  - Use DBMS_METADATA Use standard Oracle package DBMS_METADATA to get ddl. If not selected TOra will use internal routines to generate ddl.
  - Include storage information
  - Skip organisation and monitoring Exclude organisation and monitoring from storage information
  - Skip storage except tablespace Exclude all storage information except tablespace
  - Include parallel information
  - Include partition information
  - Include code
  - Include header Include TOra generated script header, containing information such as database name, time of extraction etc.
  - Include prompt

Possibility to break MySql queries
  TODO
When calling create routine statement in worksheet
  MySQL routine creation does not support "create or replace" therefore if you try to create new routine and it already exists you will get an exception. This option controls if TOra should try to avoid such exceptions in one of supported ways:
  - Do nothing - do not try to detect and avoid exception when creating routines.
  - Drop before creating - execute "drop <procedure|function> if exists <name>" before calling create statement.
  - Drop before creating (if exists) - check routines table if routine already exists. If so - execute drop statement.
  - Ask - ask user if TOra should try dropping a routine before creating it (without checking if it already exists).
  - Ask (if exists) - check routines table if routine already exists. If so - ask user if drop statement should be called (without it creating procedure will fail, but it could be usefull if you didn't know that routine with given name exists already and now you would like to skip creation and probably change the name of routine).
  Note! - if routine creation statement fails you will be left without any version of routine in the database!