1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
<HTML><HEAD><TITLE>Database Settings</TITLE></HEAD><BODY>
<H1>Database Settings</H1>
This page of the options contain settings on how to interact with the database.<P>
<IMG SRC=images/database.png><P>
<TABLE>
<TR><TD VALIGN=top>
<B>Autocommit changes</B></TD>
<TD VALIGN=top>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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Read object cache on connect</B></TD>
<TD VALIGN=top>If this checkbox is set TOra will start reading the object cache when you start
a connection to a database. If unchecked it will start reading it when it is first used. 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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Initial rows to fetch in query</B></TD>
<TD VALIGN=top>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 <B>All</B> 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 <B>All</B> box and reading a really large table could bring your machine to it's knees.
</TD></TR>
<TR><TD VALIGN=top>
<B>Initially read in content editor</B></TD>
<TD VALIGN=top>If set to something other than <B>All</B> 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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Maximum size display</B></TD>
<TD VALIGN=top>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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Run UI blocking threads exclusively in main thread.</B></TD>
<TD VALIGN=top>Let queries normally running in the background use their own connection to the
database. This is so that when a query that would block the user interface needs to be run the
main connection is more likely to be free. Background queries include many parts of the database
browser and all charts.
</TD></TR>
<TR><TD VALIGN=top>
<B>Don't reread data if query is exactly same.</B></TD>
<TD VALIGN=top>If checked TOra will not refresh a query if it is reexecuted exactly the same two times in a row.
This is mainly usefull in the schema browser when you have a slow connection and need to switch between
tabs a lot.
</TD></TR>
<TR><TD VALIGN=top>
<B>Abort long running queries and reexecute in own connection.</B></TD>
<TD VALIGN=top>If checked TOra will abort any queries running in the main connection of the database
<B>in the background</B> and reexecute them in their own connection to make you able to continue
to work in other parts of TOra until the query gives a reply. Only queries that have not given
any response at all will be aborted and moved.
</TD></TR>
<TR><TD>
<B>Move to own connection after</B></TD>
<TD VALIGN=top>The number of seconds to wait before moving the query from the main connection (See
<B>Abort long running queries and reexecute in own connection</B> above for more info).
</TD></TR>
</TABLE>
<A NAME=oracle>
There may also be pages under this for each individual database provider. Currently onlye Oracle uses
this feature. That setup looks like this.<P>
<IMG SRC=images/oracle.png>
<TABLE>
<TR><TD VALIGN=top>
<B>Checkpoint name</B></TD>
<TD VALIGN=top>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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Default date format</B></TD>
<TD VALIGN=top>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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Explain plan table</B></TD>
<TD VALIGN=top>The table to use to temporarily store explained execution plans. Use the <B>Create Table</B>
button to create the table if you don't have it.
</TD></TR>
<TR><TD VALIGN=top>
<B>Keep plans</B></TD>
<TD VALIGN=top>If this is check 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.
</TD></TR>
<TR><TD VALIGN=top>
<B>Max LONG and LOB data length</B></TD>
<TD VALIGN=top>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 <B>Unlimited</B> checkbox to the right. LONG datafields can
not be specified as <B>Unlimited</B>, if this is specified 33000 characters are read by default.
</TD></TR>
</TABLE>
</BODY>
</HTML>
|