Update of /cvsroot/firebird/manual/src/docs/firebirddocs
In directory usw-pr-cvs1:/tmp/cvs-serv9548
Modified Files:
datadefinition.xml
Log Message:
Minor changes.
Index: datadefinition.xml
===================================================================
RCS file: /cvsroot/firebird/manual/src/docs/firebirddocs/datadefinition.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -U3 -r1.1 -r1.2
--- datadefinition.xml 2002/01/10 15:35:25 1.1
+++ datadefinition.xml 2002/01/12 14:48:54 1.2
@@ -233,7 +233,7 @@
<para>Creating and dropping views</para>
</listitem>
<listitem>
- <para>Using<command>WITH CHECK OPTION</command>
+ <para>Using <command>WITH CHECK OPTION</command>
</para>
</listitem>
</itemizedlist>
@@ -353,7 +353,7 @@
<section id="datadefinition-using-isql">
<title>Using <command>isql</command>
</title>
- <para>You can use <command>isql</command> to interactively create, update, and drop metadata, or you can input a file to<command>isql</command>that contains data definition statements, which is then executed by <command>isql</command> without prompting the user. It is usually preferable to use a data definition file because it is easier to modify the file than to retype a series of individual SQL statements, and the file provides a record of the changes made to the database.</para>
+ <para>You can use <command>isql</command> to interactively create, update, and drop metadata, or you can input a file to <command>isql</command> that contains data definition statements, which is then executed by <command>isql</command> without prompting the user. It is usually preferable to use a data definition file because it is easier to modify the file than to retype a series of individual SQL statements, and the file provides a record of the changes made to the database.</para>
<para>The <command>isql</command> interface can be convenient for simple changes to existing data, or for querying the database and displaying the results. You can also use the interactive interface as a learning tool. By creating one or more sample databases, you can quickly become more familiar with <application>Firebird</application>.</para>
</section>
<section id="datadefinition-using-a-data-definition-file">
@@ -362,7 +362,7 @@
<para>
<orderedlist>
<listitem>
- <para>Use a text editor to create the data definition file. Each DDL statement should be followed by a<command>COMMIT</command>to ensure its visibility to all subsequent DDL statements in the data definition file.</para>
+ <para>Use a text editor to create the data definition file. Each DDL statement should be followed by a <command>COMMIT</command> to ensure its visibility to all subsequent DDL statements in the data definition file.</para>
</listitem>
<listitem>
<para>Save the file.</para>
@@ -884,9 +884,9 @@
<para>The default collation order that is used in sorting a column.</para>
</listitem>
</itemizedlist>
- <para>The collation order determines the order in which values are sorted. The <command>COLLATE</command> clause of <command>CREATE TABLE</command> allows users to specify a particular collation order for columns defined as <command>CHAR</command> and <command>VARCHAR</command> text datatypes. You must choose a collation order that is supported for the columnâs given character set. The collation order set at the column level overrides a collation order set at the domain level.</para>
+ <para>The collation order determines the order in which values are sorted. The <command>COLLATE</command> clause of <command>CREATE TABLE</command> allows users to specify a particular collation order for columns defined as <command>CHAR</command> and <command>VARCHAR</command> text datatypes. You must choose a collation order that is supported for the columns given character set. The collation order set at the column level overrides a collation order set at the domain level.</para>
<para>Choosing a default character set is primarily intended for users who are interested in providing a database for international use. For example, the following statement creates a database that uses the ISO8859_1 character set, typically used to support European languages:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ DEFAULT CHARACTER SET ISO8859_1; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' DEFAULT CHARACTER SET ISO8859_1; ]]></programlisting>
<para>You can override the database default character set by creating a different character set for a column when specifying the datatype. The datatype specification for a <command>CHAR, VARCHAR</command>, or <command>BLOB</command> text column definition can include a <command>CHARACTER SET</command> clause to specify a particular character set for a column. If you do not specify a character set, the column assumes the default database character set. If the database default character set is subsequently changed, all columns defined after the change have the new character set, but existing columns are not affected.</para>
<para>If you do not specify a default character set at the time the database is created, the character set defaults to <command>NONE</command>. This means that there is no character set assumption for the columns; data is stored and retrieved just as it was originally entered. You can load any character set into a column defined with <command>NONE</command>, but you cannot load that same data into another column that has been defined with a different character set. No transliteration will be performed between the source and the destination character sets.</para>
<para>For a list of the international character sets and collation orders that <application>Firebird</application> supports, see <!--link-->Chapter 13, âCharacter Sets and Collation Orders.â</para>
@@ -898,7 +898,7 @@
</section>
<section id="datadefinition-setting-default-values-and-null-status">
<title>Setting default values and <command>NULL</command> status</title>
- <para>When you define a column, you have the option of setting a <command>DEFAULT</command> value. This value is used whenever an <command>INSERT</command> or <command>UPDATE</command> on the table does not supply an explicit value for the column. Defaults can save data entry time and prevent data entry errors. For example, a possible default for a <command>DATE</command> column could be todayâs date; in a Y/N flag column for saving changes, âYâ could be the default. Column-level defaults override defaults set at the domain level.</para>
+ <para>When you define a column, you have the option of setting a <command>DEFAULT</command> value. This value is used whenever an <command>INSERT</command> or <command>UPDATE</command> on the table does not supply an explicit value for the column. Defaults can save data entry time and prevent data entry errors. For example, a possible default for a <command>DATE</command> column could be today's date; in a Y/N flag column for saving changes, âYâ could be the default. Column-level defaults override defaults set at the domain level.</para>
<para>Assign a <command>NULL</command> default to insert a <command>NULL</command> into the column if the user does not enter a value. Assign <command>NOT NULL</command> to force the user to enter a value, or to define a default value for the column. <command>NOT NULL</command> must be defined for <command>PRIMARY KEY</command> and <command>UNIQUE</command> key columns.</para>
</section>
<section id="datadefinition-defining-integrity-constraints">
@@ -1850,7 +1850,7 @@
<section id="datadefinition-when-to-break-the-rules">
<title>When to break the rules</title>
<para>You should try to correct any normalization violations, or else make a conscious decision to ignore them in the interest of ease of use or performance. Just be sure that you understand the design trade-offs that you are making, and document your reasons. It might take several iterations to reach a design that is a desirable compromise between purity and reality, but this is the heart of the design process.</para>
- <para>For example, suppose you always want data about dependents every time you look up an employee, so you decide to include <database>DEP1_NAME, DEP1_BIRTHDATE</database>, and so on for <database>DEP1</database> through <database>DEP30</database>, in the <database>EMPLOYEE</database> table. Generally speaking, that is terrible design, but the requirements of your application are more important than the abstract purity of your design. In this case, if you wanted to compute the average age of a given employeeâs dependents, you would have to explicitly add field values together, rather than asking for a simple average. If you wanted to find all employees with a dependent named âJennifer,â you would have to test 30 fields for each employee instead of one. If those are not operations that you intend to perform, then go ahead and break the rules. If the efficiency attracts you less than the simplicity, you might consider defining a view that combines records from employees with records from a separate <database>DEPENDENTS</database> table.</para>
+ <para>For example, suppose you always want data about dependents every time you look up an employee, so you decide to include <database>DEP1_NAME, DEP1_BIRTHDATE</database>, and so on for <database>DEP1</database> through <database>DEP30</database>, in the <database>EMPLOYEE</database> table. Generally speaking, that is terrible design, but the requirements of your application are more important than the abstract purity of your design. In this case, if you wanted to compute the average age of a given employee's dependents, you would have to explicitly add field values together, rather than asking for a simple average. If you wanted to find all employees with a dependent named âJennifer,â you would have to test 30 fields for each employee instead of one. If those are not operations that you intend to perform, then go ahead and break the rules. If the efficiency attracts you less than the simplicity, you might consider defining a view that combines records from employees with records from a separate <database>DEPENDENTS</database> table.</para>
<para>While you are normalizing your data, remember that <application>Firebird</application> offers direct support for array columns, so if your data includes, for example, hourly temperatures for twenty cities for a year, you could define a table with a character column that contains the city name, and a 24 by 366 matrix to hold all of the temperature data for one city for one year. This would result in a table containing 20 rows (one for each city) and two columns, one <database>NAME</database> column and one <database>TEMP_ARRAY</database> column. A normalized version of that record might have 366 rows per city, each of which would hold a city name, a Julian date, and 24 columns to hold the hourly temperatures.</para>
</section>
</section>
@@ -1858,7 +1858,7 @@
<title>Choosing indexes</title>
<para>Once you have your design, you need to consider what indexes are necessary. The basic trade-off with indexes is that more distinct indexes make retrieval by specific criteria faster, but updating and storage slower. One optimization is to avoid creating several indexes on the same column. For example, if you sometimes retrieve employees based on name, department, badge number, or department name, you should define one index for each of these columns. If a query includes more than one column value to retrieve, Firebird will use more than one index to qualify records. In contrast, defining indexes for every permutation of those three columns will actually slow both retrieval and update operations.</para>
<para>When you are testing your design to find the optimum combination of indexes, remember that the size of the tables affects the retrieval performance significantly. If you expect to have tables with 10,000 to 100,000 records each, do not run tests with only 10 to 100 records.</para>
- <para>Another factor that affects index and data retrieval times is page size. By increasing the page size, you can store more records on each page, thus reducing the number of pages used by indexes. If any of your indexes are more than 4 levels deep, you should consider increasing the page size. If indexes on volatile data (data that is regularly deleted and restored, or data that has index key values that change frequently) are less than three levels deep, you should consider reducing your page size. In general, you should use a page size larger than your largest record, although <application>Firebirdâs</application> data compression will generally shrink records that contain lots of string data, or lots of numeric values that are 0 or NULL. If your records have those characteristics, you can probably store records on pages which are 20% smaller than the full record size. On the other hand, if your records are not compressible, you should add 5% to the actual record size when
+ <para>Another factor that affects index and data retrieval times is page size. By increasing the page size, you can store more records on each page, thus reducing the number of pages used by indexes. If any of your indexes are more than 4 levels deep, you should consider increasing the page size. If indexes on volatile data (data that is regularly deleted and restored, or data that has index key values that change frequently) are less than three levels deep, you should consider reducing your page size. In general, you should use a page size larger than your largest record, although <application>Firebird's</application> data compression will generally shrink records that contain lots of string data, or lots of numeric values that are 0 or NULL. If your records have those characteristics, you can probably store records on pages which are 20% smaller than the full record size. On the other hand, if your records are not compressible, you should add 5% to the actual record size when
comparing it to the page size.</para>
<para>For more information on creating indexes, see <!--Link-->Chapter 7, âWorking with Indexes.â</para>
</section>
@@ -1867,7 +1867,7 @@
<para>When <application>Firebird</application> reads a page from the database onto disk, it stores that page in its cache, which is a set of buffers that are reserved for holding database pages. Ordinarily, the default cache size of 256 buffers is adequate. If your application includes joins of 5 or more tables, <application>Firebird</application> automatically increases the size of the cache. If your application is well localized, that is, it uses the same small part of the database repeatedly, you might want to consider increasing the cache size so that you never have to release one page from cache to make room for another.</para>
<para>You can use the <command>gfix</command> utility to increase the default number of buffers for a specific database using the following command:</para>
<programlisting><![CDATA[ gfix -buffers n database_name ]]></programlisting>
- <para>You can also change the default cache size for an entire server either by setting the value of <command>DATABASE_CACHE_PAGES</command> in the configuration file or by changing is on the <application>Firebird</application> Settings page of the <application>Firebird</application> Server Properties dialog on Windows platforms. This setting is not recommended because it affects all databases on the server and can easily result in overuse of memory or in unusably small caches. Itâs is better to tune your cache on a per-database basis using <command>gfix -buffers</command>.</para>
+ <para>You can also change the default cache size for an entire server either by setting the value of <command>DATABASE_CACHE_PAGES</command> in the configuration file or by changing is on the <application>Firebird</application> Settings page of the <application>Firebird</application> Server Properties dialog on Windows platforms. This setting is not recommended because it affects all databases on the server and can easily result in overuse of memory or in unusably small caches. It's is better to tune your cache on a per-database basis using <command>gfix -buffers</command>.</para>
<para>For more information about cache size, see the <emphasis>Embedded SQL Guide</emphasis>. For more information about using <command>gfix -buffers</command>, see the <emphasis>Operations Guide</emphasis>
</para>
</section>
@@ -1994,13 +1994,13 @@
<para>In DSQL, <command>CREATE DATABASE</command> can be executed only with <command>EXECUTE IMMEDIATE</command>. The database handle and transaction name, if present, must be initialized to zero prior to use.</para>
</important>
<para>The syntax for <command>CREATE DATABASE</command> is:</para>
- <programlisting><![CDATA[ CREATE {DATABASE | SCHEMA} âfilespecâ
- [USER âusernameâ [PASSWORD âpasswordâ]]
+ <programlisting><![CDATA[ CREATE {DATABASE | SCHEMA} 'filespec'
+ [USER 'username' [PASSWORD 'password']]
[PAGE_SIZE [=] int]
[LENGTH [=] int [PAGE[S]]]
[DEFAULT CHARACTER SET charset]
[ <secondary_file>];
-
+
<secondary_file> =FILE 'filespec' [<fileinfo>][<secondary_file>]
<fileinfo> = LENGTH [=] int [PAGE[S]] | STARTING [AT [PAGE]] int [ <fileinfo>] ]]></programlisting>
@@ -2012,12 +2012,12 @@
<para>Although there are many optional parameters, <command>CREATE DATABASE</command> requires only one parameter, <emphasis>filespec</emphasis>, which is the new database file specification. The file specification contains the device name, path name, and database name.
</para>
<para>By default, a database is created as a single file, called the <emphasis>primary file</emphasis>. The following example creates a single-file database, named <database>employee.gdb</database>, in the current directory.</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb'; ]]></programlisting>
<para>For more information about file naming conventions, see the <emphasis>Operations Guide</emphasis>.</para>
<section id="datadefinition-specifying-file-size-for-a-single-file-database">
<title>Specifying file size for a single file database</title>
<para>You can optionally specify a file length, in pages, for the primary file. For example, the following statement creates a database that is stored in one 10,000-page- long file:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ LENGTH 10000; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' LENGTH 10000; ]]></programlisting>
<para>If the database grows larger than the specified file length, <application>Firebird</application> extends the primary file beyond the <command>LENGTH</command> limit until the disk space runs out. To avoid this, you can store a database in more than one file, called a <emphasis>secondary file</emphasis>.</para>
<note>
<para>Use <command>LENGTH</command> for the primary file only if defining a secondary file in the same statement.</para>
@@ -2036,10 +2036,10 @@
<title>Secifying a secondary file using <command>LENGTH</command>
</title>
<para>The <command>LENGTH</command> parameter specifies the number of database pages for the file. The eventual maximum file size is then the number of pages times the page size for the database. (See <!--link-->"Specifying database page sizeâ) The following example creates a database with a primary file and three secondary files. The primary file and the first two secondary files are each 10,000 pages long.</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ
- FILE âemployee2.gdbâ STARTING AT PAGE 10001 LENGTH 10000 PAGES
- FILE âemployee3.gdbâ LENGTH 10000 PAGES
- FILE âemployee4.gdbâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb'
+ FILE 'employee2.gdb' STARTING AT PAGE 10001 LENGTH 10000 PAGES
+ FILE 'employee3.gdb' LENGTH 10000 PAGES
+ FILE 'employee4.gdb'; ]]></programlisting>
<note>
<para>Because file-naming conventions are platform-specific, for the sake of simplicity, none of the examples provided include the device and path name portions of the file specification.</para>
</note>
@@ -2048,15 +2048,15 @@
<title>Specifying the starting page number of a secondary file</title>
<para>If you do not declare a length for a secondary file, then you must specify a starting page number. <command>STARTING AT</command> specifies the beginning page number for a secondary file. The <command>PAGE</command> keyword is optional. You can specify a combination of length and starting page numbers for secondary files.</para>
<para>If you specify a <command>STARTING AT</command> parameter that is inconsistent with a <command>LENGTH</command> parameter for the previous file, the <command>LENGTH</command> specification takes precedence:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ LENGTH 10000
- FILE âemployee2.gdbâ LENGTH 10000 PAGES
- FILE âemployee3.gdbâ LENGTH 10000 PAGES
- FILE âemployee4.gdbâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' LENGTH 10000
+ FILE 'employee2.gdb' LENGTH 10000 PAGES
+ FILE 'employee3.gdb' LENGTH 10000 PAGES
+ FILE 'employee4.gdb'; ]]></programlisting>
<para>The following example produces exactly the same results as the previous one, but uses a mixture of <command>LENGTH</command> and <command>STARTING AT</command>:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ
- FILE âemployee2.gdbâ STARTING AT 10001 LENGTH 10000 PAGES
- FILE âemployee3.gdbâ LENGTH 10000 PAGES
- FILE âemployee4.gdbâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb'
+ FILE 'employee2.gdb' STARTING AT 10001 LENGTH 10000 PAGES
+ FILE 'employee3.gdb' LENGTH 10000 PAGES
+ FILE 'employee4.gdb'; ]]></programlisting>
</section>
</section>
<section id="datadefinition-specifying-user-name-and-password">
@@ -2066,12 +2066,12 @@
<para>Windows client applications must create their databases on a remote server. For these remote connections, the user name and password are not optional. Windows clients must provide the <command>USER</command> and <command>PASSWORD</command> options with <command>CREATE DATABASE</command> before connecting to a remote server.</para>
</important>
<para>The following statement creates a database with a user name and password:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ USER âSALESâ PASSWORD âmycodeâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' USER 'SALES' PASSWORD 'mycode'; ]]></programlisting>
</section>
<section id="datadefinition-specifying-database-page-size">
<title>Specifying database page size</title>
<para>You can override the default page size of 1024 bytes for database pages by specifying a different <command>PAGE_SIZE</command>. <command>PAGE_SIZE</command> can be 1024, 2048, 4096, or 8192. The next statement creates a single-file database with a page size of 2048 bytes:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ PAGE_SIZE 2048; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' PAGE_SIZE 2048; ]]></programlisting>
<section id="datadefinition-when-to-increase-page-size">
<title>When to increase page size</title>
<para>Increasing page size can improve performance for several reasons:</para>
@@ -2117,7 +2117,7 @@
</listitem>
</itemizedlist>
<para>Choosing a default character set is useful for all databases, even those where international use is not an issue. Choice of character set determines if transliteration among character sets is possible. For example, the following statement creates a database that uses the ISO8859_1 character set, typically used in Europe to support European languages:</para>
- <programlisting><![CDATA[ CREATE DATABASE âemployee.gdbâ DEFAULT CHARACTER SET âISO8859_1â; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE DATABASE 'employee.gdb' DEFAULT CHARACTER SET 'ISO8859_1'; ]]></programlisting>
<para>For a list of the international character sets and collation orders that <application>Firebird</application> supports, see <!--link-->Chapter 13, âCharacter Sets and Collation Orders.â</para>
<section id="datadefinition-using-character-set-none">
<title>Using character set <command>NONE</command>
@@ -2150,7 +2150,7 @@
<programlisting><![CDATA[ ALTER {DATABASE | SCHEMA}
ADD <add_clause>;
-<add_clause> = FILE âfilespecâ <fileinfo> [<add_clause>]
+<add_clause> = FILE 'filespec' <fileinfo> [<add_clause>]
<fileinfo> = {LENGTH [=] int [PAGE[S]] | STARTING [AT [PAGE]] int } [<fileinfo>] ]]></programlisting>
<para>You must specify a range of pages for each file either by providing the number of pages in each file, or by providing the starting page number for the file.</para>
@@ -2159,12 +2159,12 @@
</note>
<para>The first example adds two secondary files to the currently connected database by specifying the starting page numbers:</para>
<programlisting><![CDATA[ ALTER DATABASE
- ADD FILE âemployee2.gdbâ STARTING AT PAGE 10001
- ADD FILE âemployee3.gdbâ STARTING AT PAGE 20001 ]]></programlisting>
+ ADD FILE 'employee2.gdb' STARTING AT PAGE 10001
+ ADD FILE 'employee3.gdb' STARTING AT PAGE 20001 ]]></programlisting>
<para>The next example does nearly the same thing as the previous example, but it specifies the secondary file length rather than the starting page number. The difference is that in the previous example, the original file will grow until it reaches 10000 pages. In the second example, <application>Firebird</application> starts the secondary file at the next available page and begins using it immediately.</para>
<programlisting><![CDATA[ ALTER DATABASE
- ADD FILE âemployee2.gdbâ LENGTH 10000
- ADD FILE âemployee3.gdbâ ]]></programlisting>
+ ADD FILE 'employee2.gdb' LENGTH 10000
+ ADD FILE 'employee3.gdb' ]]></programlisting>
</section>
<section id="datadefinition-dropping-a-database">
<title>Dropping a database</title>
@@ -2273,20 +2273,20 @@
<para>These options are not mutually exclusive. For example, you can create a single-file, manual, conditional shadow.</para>
<para>The syntax of <command>CREATE SHADOW</command> is:</para>
<programlisting><![CDATA[ CREATE SHADOW set_num [AUTO | MANUAL] [CONDITIONAL]
- âfilespecâ [LENGTH [=] int [PAGE[S]]] [<secondary_file>];
+ 'filespec' [LENGTH [=] int [PAGE[S]]] [<secondary_file>];
-<secondary_file> = FILE âfilespecâ [<fileinfo>] [<secondary_file>]
+<secondary_file> = FILE 'filespec' [<fileinfo>] [<secondary_file>]
<fileinfo> = {LENGTH[=]int [PAGE[S]] | STARTING [AT [PAGE]] int } [<fileinfo>] ]]></programlisting>
<section id="datadefinition-creating-a-single-file-shadow">
<title>Creating a single-file shadow</title>
<para>To create a single-file shadow for the database <database>employee.gdb</database>, enter:</para>
- <programlisting><![CDATA[ CREATE SHADOW 1 âemployee.shdâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE SHADOW 1 'employee.shd'; ]]></programlisting>
<para>The shadow is associated with the currently connected database, <database>employee.gdb</database>. The name of the shadow file is <database>employee.shd</database>, and it is identified by a shadow set number, 1, in this example. The shadow set number tells <application>Firebird</application> that all of the shadow files listed are grouped together under this identifier.</para>
<para>To verify that the shadow has been created, enter the <command>isql</command> command <command>SHOW DATABASE</command>:</para>
<programlisting><![CDATA[ SHOW DATABASE;
Database: employee.gdb;
-Shadow 1: â/usr/Firebird/employee.shdâ auto
+Shadow 1: '/usr/Firebird/employee.shd' auto
PAGE_SIZE 1024
Number of DB pages allocated = 392
Sweep interval = 20000 ]]></programlisting>
@@ -2302,13 +2302,13 @@
<para>You can create multifile shadows, similarly to the way you create multifile databases. To create a multifile shadow, specify the name and size of each file in the shadow set. File specifications are platform-specific.</para>
<para>The following examples illustrate the creation of a multifile shadow on a UNIX platform. They create the shadow files on the A, B, and C drives of the <emphasis>IB_bckup</emphasis> node.</para>
<para>The first example creates a shadow set consisting of three files. The primary file, <database>employee.shd</database>, is 10,000 database pages in length and the first secondary file is 20,000 database pages long. The final secondary file, as always, grows as needed.</para>
- <programlisting><![CDATA[ CREATE SHADOW 1 âD:/shadows/employee.shdâ LENGTH 10000
- FILE âD:/shadows/employee2.shdâ LENGTH 5000
- FILE âD:/shadows/employee3.shdâ; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE SHADOW 1 'D:/shadows/employee.shd' LENGTH 10000
+ FILE 'D:/shadows/employee2.shd' LENGTH 5000
+ FILE 'D:/shadows/employee3.shd'; ]]></programlisting>
<para>Instead of specifying the page length of secondary files, you can specify their starting pages. The previous example could be entered as follows:</para>
- <programlisting><![CDATA[ CREATE SHADOW 1 âD:/shadows/employee.shdâ LENGTH 10000
- FILE âD:/shadows/employee2.shdâ STARTING AT 10000
- FILE âD:/shadows/employee3.shdâ STARTING AT 30000; ]]></programlisting>
+ <programlisting><![CDATA[ CREATE SHADOW 1 'D:/shadows/employee.shd' LENGTH 10000
+ FILE 'D:/shadows/employee2.shd' STARTING AT 10000
+ FILE 'D:/shadows/employee3.shd' STARTING AT 30000; ]]></programlisting>
<para>In either case, you can use <command>SHOW DATABASE</command> to verify the file names, page lengths, and starting pages for the shadow just created:</para>
<programlisting><![CDATA[ SHOW DATABASE;
Database: employee.gdb;
@@ -2320,7 +2320,7 @@
Number of DB pages allocated = 462
Sweep interval = 20000 ]]></programlisting>
<note>
- <para>The page length allocated for secondary shadow files need not correspond to the page length of the databaseâs secondary files. As the database grows and its first shadow file becomes full, updates to the database automatically overflow into the next shadow file.</para>
+ <para>The page length allocated for secondary shadow files need not correspond to the page length of the database's secondary files. As the database grows and its first shadow file becomes full, updates to the database automatically overflow into the next shadow file.</para>
</note>
</section>
<section id="datadefinition-auto-mode-and-manual-mode">
@@ -2407,7 +2407,7 @@
</section>
<section id="datadefinition-dropping-a-shadow">
<title>Dropping a shadow</title>
- <para>To stop shadowing, use the shadow number as an argument to the <command>DROP SHADOW</command> statement. <command>DROP SHADOW</command> deletes shadow references from a databaseâs metadata, as well as the physical files on disk.</para>
+ <para>To stop shadowing, use the shadow number as an argument to the <command>DROP SHADOW</command> statement. <command>DROP SHADOW</command> deletes shadow references from a database's metadata, as well as the physical files on disk.</para>
<para>A shadow can be dropped by its creator, the <command>SYSDBA</command> user, or any user with operating system root privileges.</para>
<section id="datadefinition-drop-shadow-syntax">
<title>
@@ -2418,7 +2418,7 @@
<para>If you need to look up the shadow number, use the <command>isql</command> command <command>SHOW DATABASE</command>.</para>
<programlisting><![CDATA[ SHOW DATABASE;
Database: employee.gdb;
-Shadow 1: âemployee.shdâ auto
+Shadow 1: 'employee.shd' auto
PAGE_SIZE 1024
Number of DB pages allocated = 392
Sweep interval = 20000 ]]></programlisting>
@@ -2427,7 +2427,7 @@
<section id="datadefinition-expanding-the-size-of-a-shadow">
<title>Expanding the size of a shadow</title>
<para>If a database is expected to increase in size, or if the database is already larger than the space available for a shadow on one disk, you might need to expand the size of the shadow. To do this, drop the current shadow and create a new one containing additional files. To add a shadow file, first use <command>DROP SHADOW</command> to delete the existing shadow, then use <command>CREATE SHADOW</command> to recreate it with the desired number of secondary files.</para>
- <para>The page length allocated for secondary shadow files need not correspond to the page length of the databaseâs secondary files. As the database grows and its first shadow file becomes full, updates to the database automatically overflow into the next shadow file.</para>
+ <para>The page length allocated for secondary shadow files need not correspond to the page length of the database's secondary files. As the database grows and its first shadow file becomes full, updates to the database automatically overflow into the next shadow file.</para>
</section>
<section id="datadefinition-using-isql-to-extract-data-definitions">
<title>Using <command>isql</command> to extract data definitions</title>
@@ -2436,7 +2436,7 @@
<para>The output file enables users to:</para>
<itemizedlist>
<listitem>
- <para>Examine the current state of a databaseâs system tables before planning alterations. This is especially useful when the database has changed significantly since its creation.</para>
+ <para>Examine the current state of a database's system tables before planning alterations. This is especially useful when the database has changed significantly since its creation.</para>
</listitem>
<listitem>
<para>Create a database with schema definitions that are identical to the extracted database.</para>
|
