mirror of https://github.com/tLDP/LDP
1407 lines
72 KiB
Plaintext
1407 lines
72 KiB
Plaintext
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
|
|
|
<article id="index">
|
|
<articleinfo>
|
|
|
|
<title>Sybase Adaptive Server Anywhere for Linux HOWTO</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Aylwin</firstname>
|
|
<surname>Lo</surname>
|
|
</author>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
<surname>Slee</surname>
|
|
<affiliation>
|
|
<orgname>Sybase Inc.</orgname>
|
|
<address>
|
|
<email>Tom.Slee@sybase.com</email>
|
|
</address>
|
|
</affiliation>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>1.0</revnumber>
|
|
<date>2001-04-26</date>
|
|
<authorinitials>al</authorinitials>
|
|
<revremark>
|
|
First public release.
|
|
</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
|
|
<abstract>
|
|
<para>
|
|
This HOWTO guides you through the installation of SQL Anywhere
|
|
Studio 7.0.2 for Linux and the basic operation and administration
|
|
of Adaptive Server Anywhere databases.
|
|
</para>
|
|
</abstract>
|
|
|
|
</articleinfo>
|
|
|
|
<sect1 id="intro"><title>Introduction</title>
|
|
<para>This HOWTO guides you through the installation of SQL Anywhere
|
|
Studio 7.0.2 for Linux and the basic operation and administration
|
|
of Adaptive Server Anywhere databases.</para>
|
|
|
|
<sect2><title>New versions of this document</title>
|
|
<para>The latest version of this document should always be available
|
|
at the Linux Documentation project website (<ulink url="http://www.linuxdoc.org/">http://www.linuxdoc.org/</ulink>).</para>
|
|
</sect2>
|
|
|
|
<sect2><title>Content and Audience</title>
|
|
<para>
|
|
Within this document, you will find a list
|
|
of the supported Linux distributions ("<xref linkend="requirements">").
|
|
It is intended for moderately
|
|
experienced users of Linux or UNIX. Familiarity with relational
|
|
database concepts is certainly useful, but not a requirement.
|
|
"<xref linkend="dbconcepts">"
|
|
contains a summary of relational database concepts. </para></sect2>
|
|
|
|
<sect2><title>Adaptive Server Anywhere features</title>
|
|
<para>Adaptive Server Anywhere (Adaptive Server Anywhere) is the
|
|
full SQL relational database management system at the heart of SQL
|
|
Anywhere Studio. Ideally suited for use as an embedded database,
|
|
in mobile computing, or as a workgroup server, it includes the following among
|
|
its features: </para>
|
|
<itemizedlist><listitem><para>Economical hardware requirements </para></listitem>
|
|
<listitem><para>Designed to operate without administration</para></listitem>
|
|
<listitem><para>Designed for mobile computing and synchronization</para></listitem>
|
|
<listitem><para>Ease of use</para></listitem>
|
|
<listitem><para>High performance</para></listitem>
|
|
<listitem><para>Cross-platform solution</para></listitem>
|
|
<listitem><para>Standalone and network use</para></listitem>
|
|
<listitem><para>Industry standard interfaces</para></listitem></itemizedlist>
|
|
<para>Some of the more specific features include: </para>
|
|
<itemizedlist><listitem><para>Stored procedures and triggers </para></listitem>
|
|
<listitem><para>Java support for logic and datatypes </para></listitem></itemizedlist>
|
|
<para>For further details about Adaptive Server Anywhere, please
|
|
visit the following links:</para>
|
|
<itemizedlist><listitem><para><ulink url="http://www.sybase.com/detail/1,3693,1002624,00.html">http://www.sybase.com/detail/1,3693,1002624,00.html</ulink> is
|
|
a datasheet on SQL Anywhere Studio. It includes some data on
|
|
Adaptive Server Anywhere, which ships as a component of SQL Anywhere
|
|
Studio. </para></listitem>
|
|
<listitem><para><ulink url="http://www.sybase.com/detail/1,3693,1009210,00.html">http://www.sybase.com/detail/1,3693,1009210,00.html</ulink>
|
|
has some information on the features and system requirements of
|
|
SQL Anywhere Studio and points you to the download location for
|
|
SQL Anywhere Studio for Linux 7.0. </para></listitem></itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2><title>Quirks</title>
|
|
<sect3><title>Alt and Function keys</title>
|
|
<para>Sometimes the Alt keys or the F1-F10 keys may not function
|
|
in the terminal where you are running Interactive SQL. </para>
|
|
<para>To emulate the Alt key, press Ctrl-A. Then press whatever
|
|
key was to be pressed with the Alt key. For example, instead of
|
|
pressing Alt-F, you would press Ctrl-A, then F. </para>
|
|
<para>To emulate the function keys, press Ctrl-F, followed by the
|
|
number of the function key you wanted to press. For example, instead
|
|
of pressing F9, you would press Ctrl-F, then 9. For F10, use the
|
|
zero key. </para></sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="dbconcepts"><title>What's a Relational Database?</title>
|
|
<para>If you are already familiar with relational databases, you
|
|
can skip this section. </para>
|
|
<sect3><title>Definition</title>
|
|
<para>A <emphasis>relational database-management system</emphasis> (RDBMS)
|
|
is a system for storing and retrieving data, in which the data is
|
|
organized in tables. A relational database consists of a collection
|
|
of tables that store interrelated data. </para>
|
|
<para>If that doesn't quite make sense yet, read on. </para></sect3>
|
|
<sect3><title>Example</title>
|
|
<para>Suppose you have some software to keep track of sales orders,
|
|
and each order is stored in the form of a table, called sales_order.
|
|
It has information about the customer (for example, her name, address
|
|
and phone number), the date of the order, and information about
|
|
the sales representative (for example his name, department, and
|
|
office phone number). Let's put all this into a table, with the
|
|
data for a few orders: </para>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title>The sales_order
|
|
table</title><tgroup cols = "8" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "0.931in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "1.333in">
|
|
<colspec colname = "3" colnum = "3" colwidth = "1.750in">
|
|
<colspec colname = "4" colnum = "4" colwidth = "1.083in">
|
|
<colspec colname = "5" colnum = "5" colwidth = "0.917in">
|
|
<colspec colname = "6" colnum = "6" colwidth = "1.000in">
|
|
<colspec colname = "7" colnum = "7" colwidth = "0.833in">
|
|
<colspec colname = "8" colnum = "8" colwidth = "1.014in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>cust_name</emphasis></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>cust_address</emphasis></entry>
|
|
<entry colname = "3" valign = "top"><emphasis>cust_city_state_zip</emphasis></entry>
|
|
<entry colname = "4" valign = "top"><emphasis>cust_phone</emphasis></entry>
|
|
<entry colname = "5" valign = "top"><emphasis>order_date</emphasis></entry>
|
|
<entry colname = "6" valign = "top"><emphasis>emp_name</emphasis></entry>
|
|
<entry colname = "7" valign = "top"><emphasis>emp_dept</emphasis></entry>
|
|
<entry colname = "8" valign = "top"><emphasis>emp_phone</emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">M. Devlin</entry>
|
|
<entry colname = "2" valign = "top">3114 Pioneer Ave.</entry>
|
|
<entry colname = "3" valign = "top">Rutherford, NJ 07070</entry>
|
|
<entry colname = "4" valign = "top">2015558966</entry>
|
|
<entry colname = "5" valign = "top">19930316</entry>
|
|
<entry colname = "6" valign = "top">R. Overbey</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">5105557255</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">M. Devlin</entry>
|
|
<entry colname = "2" valign = "top">3114 Pioneer Ave.</entry>
|
|
<entry colname = "3" valign = "top">Rutherford, NJ 07070</entry>
|
|
<entry colname = "4" valign = "top">2015558966</entry>
|
|
<entry colname = "5" valign = "top">19940405</entry>
|
|
<entry colname = "6" valign = "top">M. Kelly</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">5085553769</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">J. Gagliardo</entry>
|
|
<entry colname = "2" valign = "top">2800 Park Ave.</entry>
|
|
<entry colname = "3" valign = "top">Hull, PQ K1A 0H3</entry>
|
|
<entry colname = "4" valign = "top">8195559539</entry>
|
|
<entry colname = "5" valign = "top">19940326</entry>
|
|
<entry colname = "6" valign = "top">M.Garcia</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">7135553431</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">E. Peros</entry>
|
|
<entry colname = "2" valign = "top">50 Market St.</entry>
|
|
<entry colname = "3" valign = "top">Rochester, NY 14624</entry>
|
|
<entry colname = "4" valign = "top">7165554275</entry>
|
|
<entry colname = "5" valign = "top">19930603</entry>
|
|
<entry colname = "6" valign = "top">P. Chin</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">4045552341</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">E. Peros</entry>
|
|
<entry colname = "2" valign = "top">50 Market St.</entry>
|
|
<entry colname = "3" valign = "top">Rochester, NY 14624</entry>
|
|
<entry colname = "4" valign = "top">7165554275</entry>
|
|
<entry colname = "5" valign = "top">19940127</entry>
|
|
<entry colname = "6" valign = "top">M.Garcia</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">7135553431</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">E. Peros</entry>
|
|
<entry colname = "2" valign = "top">50 Market St.</entry>
|
|
<entry colname = "3" valign = "top">Rochester, NY 14624</entry>
|
|
<entry colname = "4" valign = "top">7165554275</entry>
|
|
<entry colname = "5" valign = "top">19940520</entry>
|
|
<entry colname = "6" valign = "top">J. Klobucher</entry>
|
|
<entry colname = "7" valign = "top">Sales</entry>
|
|
<entry colname = "8" valign = "top">7135558627</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<para>Everything appears nice and ordered, but there's a fair bit
|
|
of redundancy. M. Devlin's name appears twice, along with his address
|
|
and phone number. E. Peros' details appear three times. If you look
|
|
carefully at the employee side of things, you'll notice that M.
|
|
Garcia is repeated, as well. </para>
|
|
<para>Wouldn't it be nice if you could separate that information
|
|
and only store it once, rather than several times? In the long term,
|
|
it would certainly save disk space and allow for greater flexibility.
|
|
Since redundant data entry is minimized, it would also reduce the
|
|
chances of erroneous data entering the database, increasing consistency.
|
|
Well, we can see three different entities involved here: the customer,
|
|
the order, and the employee. So let's take each of the individuals,
|
|
put them into categories, and give them identification numbers so
|
|
they can be referenced. </para>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title>The customer
|
|
table</title><tgroup cols = "5" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "0.431in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "1.000in">
|
|
<colspec colname = "3" colnum = "3" colwidth = "1.333in">
|
|
<colspec colname = "4" colnum = "4" colwidth = "1.500in">
|
|
<colspec colname = "5" colnum = "5" colwidth = "1.000in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>id</emphasis></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>name</emphasis></entry>
|
|
<entry colname = "3" valign = "top"><emphasis>address</emphasis></entry>
|
|
<entry colname = "4" valign = "top"><emphasis>city_state_zip</emphasis></entry>
|
|
<entry colname = "5" valign = "top"><emphasis>phone</emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">101</entry>
|
|
<entry colname = "2" valign = "top">M. Devlin</entry>
|
|
<entry colname = "3" valign = "top">3114 Pioneer Ave.</entry>
|
|
<entry colname = "4" valign = "top">Rutherford, NJ 07070</entry>
|
|
<entry colname = "5" valign = "top">2015558966</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">109</entry>
|
|
<entry colname = "2" valign = "top">J. Gagliardo</entry>
|
|
<entry colname = "3" valign = "top">2800 Park Ave.</entry>
|
|
<entry colname = "4" valign = "top">Hull, PQ K1A 0H3</entry>
|
|
<entry colname = "5" valign = "top">8195559539</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">180</entry>
|
|
<entry colname = "2" valign = "top">E. Peros</entry>
|
|
<entry colname = "3" valign = "top">50 Market St.</entry>
|
|
<entry colname = "4" valign = "top">Rochester, NY 14624</entry>
|
|
<entry colname = "5" valign = "top">7165554275</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title>The employee
|
|
table</title><tgroup cols = "4" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "0.431in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "1.000in">
|
|
<colspec colname = "3" colnum = "3" colwidth = "0.583in">
|
|
<colspec colname = "4" colnum = "4" colwidth = "1.000in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>id</emphasis></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>name</emphasis></entry>
|
|
<entry colname = "3" valign = "top"><emphasis>dept</emphasis></entry>
|
|
<entry colname = "4" valign = "top"><emphasis>phone</emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">299</entry>
|
|
<entry colname = "2" valign = "top">R. Overbey</entry>
|
|
<entry colname = "3" valign = "top">Sales</entry>
|
|
<entry colname = "4" valign = "top">5105557255</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">902</entry>
|
|
<entry colname = "2" valign = "top">M. Kelly</entry>
|
|
<entry colname = "3" valign = "top">Sales</entry>
|
|
<entry colname = "4" valign = "top">5085553769</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">667</entry>
|
|
<entry colname = "2" valign = "top">M.Garcia</entry>
|
|
<entry colname = "3" valign = "top">Sales</entry>
|
|
<entry colname = "4" valign = "top">7135553431</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">129</entry>
|
|
<entry colname = "2" valign = "top">P. Chin</entry>
|
|
<entry colname = "3" valign = "top">Sales</entry>
|
|
<entry colname = "4" valign = "top">4045552341</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">467</entry>
|
|
<entry colname = "2" valign = "top">J. Klobucher</entry>
|
|
<entry colname = "3" valign = "top">Sales</entry>
|
|
<entry colname = "4" valign = "top">7135558627</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title>The new sales_order
|
|
table</title><tgroup cols = "4" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "0.514in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "0.667in">
|
|
<colspec colname = "3" colnum = "3" colwidth = "0.917in">
|
|
<colspec colname = "4" colnum = "4" colwidth = "1.000in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>id</emphasis></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>cust_id</emphasis></entry>
|
|
<entry colname = "3" valign = "top"><emphasis>order_date</emphasis></entry>
|
|
<entry colname = "4" valign = "top"><emphasis>sales_rep_id</emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">2001</entry>
|
|
<entry colname = "2" valign = "top">101</entry>
|
|
<entry colname = "3" valign = "top">19930316</entry>
|
|
<entry colname = "4" valign = "top">299</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">2583</entry>
|
|
<entry colname = "2" valign = "top">101</entry>
|
|
<entry colname = "3" valign = "top">19940405</entry>
|
|
<entry colname = "4" valign = "top">902</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">2576</entry>
|
|
<entry colname = "2" valign = "top">109</entry>
|
|
<entry colname = "3" valign = "top">19940326</entry>
|
|
<entry colname = "4" valign = "top">667</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">2081</entry>
|
|
<entry colname = "2" valign = "top">180</entry>
|
|
<entry colname = "3" valign = "top">19930603</entry>
|
|
<entry colname = "4" valign = "top">129</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">2503</entry>
|
|
<entry colname = "2" valign = "top">180</entry>
|
|
<entry colname = "3" valign = "top">19940127</entry>
|
|
<entry colname = "4" valign = "top">667</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">2640</entry>
|
|
<entry colname = "2" valign = "top">180</entry>
|
|
<entry colname = "3" valign = "top">19940520</entry>
|
|
<entry colname = "4" valign = "top">467</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<para>As you can see, each customer's information is stored only
|
|
once, and the same goes for each employee. The sales_order table
|
|
is a lot smaller, too. Each row, representing a sales order, refers
|
|
to a cust_id and an emp_id. </para>
|
|
<para>By looking up the customer corresponding to a cust_id (which
|
|
is unique), one can find all the needed data on that customer, without
|
|
having to repeat it in sales_order. In addition, an id column has
|
|
been added. Its purpose will be explained in the next section. </para>
|
|
<para>Why do this, you ask? By eliminating redundancy, this kind
|
|
of structure reduces the opportunities for inconsistencies to seep
|
|
in, in addition to lowering storage requirements. If you had to
|
|
change E. Peros' address in the old sales_order table, you'd have
|
|
to do it three times, which would take three times as long and give
|
|
you three times as many chances to make an error. In the newer table,
|
|
all you'd have to do is change her address once, in the customer
|
|
table. Also, by carefully separating data, you make access control
|
|
simpler. </para>
|
|
<para>Finally, can you spot another redundancy? The employee table
|
|
has "Sales" all the way down the dept column. For an organization
|
|
with multiple departments, you'd want to add a department table
|
|
and reference it from a dept_id column instead. </para></sect3>
|
|
|
|
<sect3><title>Primary and Foreign Keys</title>
|
|
<para>As described in the previous section, you can separate a table
|
|
into interrelated tables. But how do you go about relating tables
|
|
to each other? In relational databases, primary keys and foreign
|
|
keys help you link tables together. Primary keys are columns that
|
|
uniquely identify each row of a table, and foreign keys define the
|
|
relationship between the rows of two separate tables. Proper use
|
|
of primary and foreign keys will help you efficiently hold information
|
|
without excessive redundancy. </para>
|
|
<para>Every table should have a primary key to ensure that each
|
|
row is uniquely identified. This often takes the form of an ID number
|
|
being assigned to each row, as in the previous section's example.
|
|
The id column forms the primary key. </para>
|
|
<para>As long as you can guarantee the uniqueness of the data in
|
|
a particular column, though, that column can be a primary key. For
|
|
example, if you only want one entry per day to be put into a particular
|
|
table, you could use the date as that table's primary key. </para>
|
|
<para>Tables are related to one another by foreign keys. In the
|
|
sales_order example, the cust_id and sales_rep columns would be
|
|
called foreign keys to the customer and employee tables, respectively.
|
|
For terminology's sake, you might want to know that in this case,
|
|
the sales_order table is called the <emphasis>foreign</emphasis> or <emphasis>referencing</emphasis> table,
|
|
while the customer and employee tables are called the <emphasis>primary</emphasis> or <emphasis>referenced</emphasis> tables. </para></sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="requirements"><title>Requirements</title>
|
|
<sect2><title>System requirements</title>
|
|
<para>Adaptive Server Anywhere requires that you have the following
|
|
installed on your system:</para>
|
|
<itemizedlist><listitem><para>kernel 2.2.5-15 and up (2.2.x series) </para></listitem>
|
|
<listitem><para>glibc-2.1 or up </para></listitem>
|
|
<listitem><para>pthreads-0.8 or higher (included usually as part
|
|
of glibc)</para></listitem>
|
|
<listitem><para>libstdc++-2-libc6.1 </para></listitem></itemizedlist></sect2>
|
|
|
|
<sect2><title>Supported distributions</title>
|
|
<para>At present, the following Linux distributions are supported: </para>
|
|
<itemizedlist><listitem><para>Caldera 2.4 </para></listitem>
|
|
<listitem><para>Red Hat 7.0, 6.2, 6.1 or 6.0 </para></listitem>
|
|
<listitem><para>TurboLinux 6.1 </para></listitem>
|
|
<listitem><para>SuSE 7.0, 6.4, 6.3 or 6.2 </para></listitem></itemizedlist>
|
|
<para>NOTE: The glibc and gcc released with Red Hat Linux 7.0 require
|
|
patches before you can use Adaptive Server Anywhere. You can find
|
|
them at <ulink url="http://www.redhat.com/support/errata/rh7-errata-bugfixes.html">http://www.redhat.com/support/errata/rh7-errata-bugfixes.html</ulink>. </para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="install"><title>Installation</title>
|
|
<sect2><title>Process</title>
|
|
<orderedlist><listitem><para>Log on as root. </para></listitem>
|
|
<listitem><para>Place the CD-ROM into the CD-ROM drive. </para></listitem>
|
|
<listitem><para>Mount the CD-ROM. Usually, it gets mounted to /mnt/cdrom.
|
|
If so, enter the following command: </para>
|
|
<para><command>mount /mnt/cdrom</command></para></listitem>
|
|
<listitem><para>At a command prompt, change to the CD-ROM directory.
|
|
If the CD-ROM was mounted to /mnt/cdrom/, use the following command: </para>
|
|
<para><command>cd /mnt/cdrom</command></para></listitem>
|
|
<listitem><para>Start the setup script by entering the following
|
|
command: </para>
|
|
<para><command>./setup</command></para></listitem>
|
|
<listitem><para>The setup script prompts you with information about
|
|
installing SQL Anywhere Studio for UNIX. Enter any information you
|
|
are prompted for, and press the Enter key to continue. </para></listitem></orderedlist>
|
|
<para>By default, SQL Anywhere Studio is installed into a directory
|
|
named SYBSsa7 under /opt/sybase on Solaris, Linux, and HP-UX, and
|
|
under /usr/lpp/sybase on AIX. You can specify another installation
|
|
directory if you wish. </para>
|
|
</sect2>
|
|
<sect2><title>Distribution-specific considerations
|
|
(for TurboLinux and Caldera)</title>
|
|
<para>After installation, you should follow these instructions if
|
|
you are running either TurboLinux 6.0 or Caldera 2.2. </para>
|
|
<para>For TurboLinux 6.0 only, change to directory /usr/lib and
|
|
create a symbolic link using the following command. </para>
|
|
<para><command>ln -s libstdc++-libc6.1-2.so.3 libstdc++-libc6.1-1.so.2 </command></para>
|
|
<para>For Caldera 2.2 only, change to directory /usr/lib and create
|
|
a symbolic link using the following command. </para>
|
|
<para><command>ln -s /usr/lib/libstdc++-2.9.0 /usr/lib/libstdc++-libc6.1-1.so.2 </command></para></sect2>
|
|
<sect2><title>Setting the Environment Variables</title>
|
|
<para>Each user who uses the software must set the necessary environment
|
|
variables for Adaptive Server Anywhere. To help you do that, the
|
|
installation program puts two script files, asa_config.sh and asa_config.csh,
|
|
in the directory /<emphasis>InstallDir</emphasis>/SYBSsa7/bin. <emphasis>InstallDir</emphasis> is
|
|
the directory where you chose to install Adaptive Server Anywhere. </para>
|
|
<para>Depending on which shell you're using, enter the appropriate
|
|
command from <emphasis>InstallDir</emphasis>. </para>
|
|
<table colsep = "1" frame = "all" rowsep = "1" tocentry = "1"><title></title>
|
|
<tgroup charoff = "50" cols = "2" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "2.292in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "3.153in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>If you're using this shell...</emphasis></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>...use this command.</emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">sh, ksh, bash</entry>
|
|
<entry colname = "2" valign = "top">. ./SYBSsa7/bin/asa_config.sh</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">csh, tcsh</entry>
|
|
<entry colname = "2" valign = "top">source ./SYBSsa7/bin/asa_config.csh</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<para>You may also want to insert the above commands into your copy
|
|
of .profile or .bash_profile to have the environment variables ready
|
|
every time you log in. </para></sect2>
|
|
<sect2><title>Where did it get installed?</title>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title></title><tgroup
|
|
cols = "2" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "5.347in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "3.514in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Most Adaptive Server Anywhere
|
|
command line utilities (names beginning with db)</entry>
|
|
<entry colname = "2" valign = "top">/<emphasis>InstallDir</emphasis>/SYBSsa7/bin</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Sybase Central</entry>
|
|
<entry colname = "2" valign = "top">/<emphasis>InstallDir</emphasis>/shared/sybcentral40/java</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Sample database</entry>
|
|
<entry colname = "2" valign = "top">/<emphasis>InstallDir</emphasis>/SYBSsa7</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">Online documentation</entry>
|
|
<entry colname = "2" valign = "top">/<emphasis>CDROM</emphasis>/help/contents.htm
|
|
or/InstallDir/SYBSsa7/doc/contents.htm</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<para><emphasis>CDROM</emphasis> is the directory where your CD-ROM
|
|
is mounted, which is usually /mnt/cdrom/. </para>
|
|
<para><emphasis>InstallDir</emphasis> is the directory where you
|
|
chose to install Adaptive Server Anywhere. </para>
|
|
<para>The first two directories are put into the path by asa_config.sh
|
|
or asa_config.csh, so if you've already executed one of them as
|
|
mentioned in the previous section, you won't have to change directories
|
|
to get to most of the executables associated with Adaptive Server
|
|
Anywhere. </para></sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1><title>Creating, Running and Connecting to Databases</title>
|
|
|
|
<sect2><title>Creating a database</title>
|
|
<para>When you ask Adaptive Server Anywhere to create a database,
|
|
it creates the main database file, which contains the following
|
|
objects, among others: </para>
|
|
<itemizedlist><listitem><para>user tables </para></listitem>
|
|
<listitem><para>indexes </para></listitem>
|
|
<listitem><para>views </para></listitem>
|
|
<listitem><para>system tables </para></listitem></itemizedlist>
|
|
<para>The maximum size of a database file depends on your file system
|
|
and the page size you choose. Database files are limited to 256
|
|
million database pages or the filesize limit, whichever is reached
|
|
first. UNIX files can be as large as 1 Tb, in some cases-see the
|
|
Physical Limitations chapter of the Adaptive Server Anywhere Reference
|
|
Manual or your Linux documentation for more information. You can
|
|
set pages to be 1, 2, 4, 8, 16, or 32 kb in size, but it is not
|
|
recommended that you use a page size of 1 kb. The default page size
|
|
is 2 kb. </para>
|
|
<para>By default, Adaptive Server Anywhere also creates a file called
|
|
the <emphasis>transaction log</emphasis>. Besides improving performance,
|
|
the transaction log is vital to Adaptive Server Anywhere replication
|
|
systems and database recovery in event of system failures. When possible,
|
|
it is recommended that the transaction log be placed on a physical
|
|
device (in most cases, a disk drive) separate from the main database
|
|
file, to reduce the chances of both the main database file and transaction
|
|
log being affected in the event of a media failure. You can specify
|
|
the name and location of the transaction log when you create the
|
|
database. </para>
|
|
<para>This section shows you how to create databases at either the
|
|
command prompt or in Interactive SQL. You can also create databases
|
|
through Sybase Central, if you prefer, by opening the Utilities
|
|
folder under Adaptive Server Anywhere 7. </para>
|
|
|
|
<sect3 id = "Asa-41htmltoc511556197"><title>Creating a database
|
|
from the command prompt</title>
|
|
<para>The command line utility for creating a database is <emphasis>dbinit</emphasis>.</para>
|
|
<para>Syntax: </para>
|
|
<para><command>dbinit [switches] db-file-name</command></para>
|
|
<para>db-file-name is the name you would like to give to your database
|
|
file, for example, mydb.db. If you issue the command "dbinit -?"
|
|
you'll be shown the above syntax, along with a list of options you
|
|
can use. </para>
|
|
<para>To create your first Adaptive Server Anywhere database on
|
|
Linux, enter the following command: </para>
|
|
<para><command>dbinit -t './logs/mydb.log' p 4096 mydb.db</command></para>
|
|
<para>This command creates a database in the current working directory
|
|
called mydb.db with a page size of 4096 bytes, specified by the
|
|
-p switch. Assuming the directory exists, it also creates the transaction
|
|
log mydb.log in the subdirectory "logs," specified by the -t switch.
|
|
Adaptive Server Anywhere databases carry the extension ".db" . </para></sect3>
|
|
|
|
<sect3 id = "Asa-41htmltoc511556198"><title>Creating a database
|
|
from Sybase Central</title>
|
|
<para>To create a database in Sybase Central, open the Adaptive
|
|
Server Anywhere section of the left pane, and select Utilities.
|
|
Double-click Create Database in the right pane, and follow the on-screen
|
|
instructions. </para></sect3>
|
|
</sect2>
|
|
|
|
<sect2><title>Running a database server and starting databases</title>
|
|
<para>There are two versions of the database server installed on
|
|
your machine. If you are just using Adaptive Server Anywhere locally,
|
|
use the personal database server (dbeng7). If you are going to connect
|
|
to the Adaptive Server Anywhere database over a network, however,
|
|
you should use the network database server (dbsrv7). Examples in
|
|
this document use dbeng7, but the two commands are, for the most
|
|
part, interchangeable. See the table below for specific differences. </para>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title>Differences
|
|
between the Personal and Network database servers</title><tgroup
|
|
cols = "3" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "3.833in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "2.500in">
|
|
<colspec colname = "3" colnum = "3" colwidth = "2.431in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"></entry>
|
|
<entry colname = "2" valign = "top"><emphasis>Personal database server </emphasis></entry>
|
|
<entry colname = "3" valign = "top"><emphasis>Network database server </emphasis></entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Name of executable</entry>
|
|
<entry colname = "2" valign = "top">dbeng7</entry>
|
|
<entry colname = "3" valign = "top">dbsrv7</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Local connections</entry>
|
|
<entry colname = "2" valign = "top">Yes</entry>
|
|
<entry colname = "3" valign = "top">Yes</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Network connections</entry>
|
|
<entry colname = "2" valign = "top">No</entry>
|
|
<entry colname = "3" valign = "top">Yes</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Maximum number of connections</entry>
|
|
<entry colname = "2" valign = "top">10</entry>
|
|
<entry colname = "3" valign = "top">Depends on license</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Available communications protocols</entry>
|
|
<entry colname = "2" valign = "top">Shared memory, TCP/IP</entry>
|
|
<entry colname = "3" valign = "top">Shared memory, TCP/IP</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top">Maximum number of CPUs for request
|
|
processing</entry>
|
|
<entry colname = "2" valign = "top">2</entry>
|
|
<entry colname = "3" valign = "top">Unlimited</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top">Default/Maximum number of internal
|
|
threads </entry>
|
|
<entry colname = "2" valign = "top">10/10</entry>
|
|
<entry colname = "3" valign = "top">20/Unlimited</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
<para>Syntax: </para>
|
|
<para><command>(dbeng7 | dbsrv7) [server-switches] [database-file [database-switches],
|
|
] </command></para>
|
|
<para>database-file specifies the path and filename to the database.
|
|
You aren't actually required to specify a database file when you
|
|
start up the database server, but if you don't, you must specify a
|
|
name for the server using the -n switch. By default, if you do not
|
|
specify a name for the database, it takes on the name of the database
|
|
file, minus the path and extension. Similarly, if you do not specify
|
|
a name for the database server (which you can do in server-switches),
|
|
it takes on the name of the first database that was started on it. </para>
|
|
<para>For full details on the usage of dbeng7 and dbsrv7, see "The
|
|
database server" in the Adaptive Server Anywhere Reference. </para>
|
|
<para>To start up the Adaptive Server Anywhere personal database
|
|
server, but not a database, and name it MyServer, issue the following
|
|
command at a prompt: </para>
|
|
<para><command>dbeng7 -n MyServer </command></para>
|
|
<para>To start up the Adaptive Server Anywhere personal database
|
|
server and name it MyServer, then start a database on MyServer from
|
|
mydb.db, naming it MyDatabase, issue the following command: </para>
|
|
<para><command>dbeng7 -n MyServer mydb.db -n MyDatabase </command></para>
|
|
<para>In the latter case, if you don't name the database server
|
|
MyServer, it would be named MyDatabase instead. </para>
|
|
<para>There's a plethora of other switches available for the server.
|
|
You can get a full listing of them by typing "dbeng7 -?" at a command
|
|
prompt. A few important switches include the following: </para>
|
|
<itemizedlist><listitem><para>-c, for specifying Adaptive Server
|
|
Anywhere's cache size </para></listitem>
|
|
<listitem><para>-x allows you to specify the communications protocols </para></listitem>
|
|
<listitem><para>-gt allows you to specify the number of processors
|
|
to be used </para></listitem>
|
|
<listitem><para>-ud tells the server to run as a daemon in UNIX
|
|
(explained below) </para></listitem></itemizedlist>
|
|
|
|
<sect3><title>Running the server as a daemon</title>
|
|
<para>Sometimes it's necessary for the server to run outside of
|
|
the current session (that is, regardless of who, if anyone, is logged
|
|
in). To do so, use the -ud switch at the command line when starting
|
|
the server to run it as a daemon. </para>
|
|
<para>The following command would start up a database server as
|
|
a daemon, using the database we created before: </para>
|
|
<para><command>dbsrv7 -ud -n MyDatabase mydb.db</command> </para>
|
|
<para>NOTE: Using "&" to run the database server in the background
|
|
does not work. </para></sect3>
|
|
</sect2>
|
|
|
|
<sect2><title>Stopping the database server</title>
|
|
<para>Assuming you have the appropriate authority, you can stop
|
|
the database server using any of the following methods: </para>
|
|
<itemizedlist><listitem><para>the dbstop command line utility </para></listitem>
|
|
<listitem><para>using the STOP ENGINE SQL statement </para></listitem>
|
|
<listitem><para>pressing the Q key when the server display window
|
|
has the focus </para></listitem></itemizedlist>
|
|
<para>NOTE: While the term <emphasis>engine</emphasis> is part of
|
|
the SQL statement's name, <emphasis>server</emphasis> is the common
|
|
term now used. This document will use the term <emphasis>server</emphasis> unless
|
|
referring explicitly to the STOP ENGINE SQL statement. </para>
|
|
<para>By default, any user can stop a personal database server,
|
|
but only a user with the DBA authority can stop a network database
|
|
server. (This default can be changed by using the -gk switch when
|
|
starting the server-see the Adaptive Server Anywhere Reference for
|
|
details.) </para>
|
|
<para>The command line utility syntax is as follows: </para>
|
|
<para><command>dbstop [switches] {name}</command></para>
|
|
<para>If you are issuing dbstop to stop a locally-running server,
|
|
you can simply specify the name of the database server in {name}.
|
|
If the server is not running locally, you need to create a connection
|
|
to the server before you can tell it to stop. The -c switch allows
|
|
you to specify a connection string for the database running on the
|
|
server that you would like to stop. To stop MyServer, execute the
|
|
following command: </para>
|
|
<para><command>dbstop -c "uid=DBA;pwd=SQL;eng=MyServer;dbn=MyDatabase"</command></para>
|
|
<para>In this instance, you could also just give the server name,
|
|
since the server is running locally: </para>
|
|
<para><command>dbstop MyServer </command></para>
|
|
<para>The first command connects to the database named MyDatabase
|
|
on the server MyServer, then stops the server named MyServer. In
|
|
the case that no databases are active on the server, you have to
|
|
add "dbn=utility_db" to the connection string.</para>
|
|
<para>Let's say "Club" is the name of one of the databases running
|
|
on a server named "Goliath," and you want to stop all the databases
|
|
running on Goliath, including Club. The following command accomplishes
|
|
that, as well as shutting down the database server: </para>
|
|
<para><command>dbstop -c "uid=DBA;pwd=SQL;eng=Goliath;dbn=Club"</command></para>
|
|
<para>If you have a database server named "David" running without
|
|
any databases started on it, you can stop the server using the following
|
|
command: </para>
|
|
<para><command>dbstop -c "uid=DBA;pwd=SQL;eng=David;dbn=utility_db"</command></para>
|
|
<para>The syntax for the STOP ENGINE statement is as follows: </para>
|
|
<para><command>STOP ENGINE [ server-name ] [ UNCONDITIONALLY ] </command></para>
|
|
<para>The server named server-name is stopped. If server-name is
|
|
omitted, the currently running database server is stopped. If UNCONDITIONALLY
|
|
is specified, the database server is stopped whether or not there
|
|
are still connections to the server. </para>
|
|
</sect2>
|
|
|
|
<sect2><title>Stopping databases</title>
|
|
<para>It's also possible to stop individual databases without stopping
|
|
the server, or any of the other databases that might be running
|
|
on it. To do so, use the STOP DATABASE SQL statement.</para>
|
|
<para>Syntax: </para>
|
|
<para><command>STOP DATABASE database-name [ON engine-name] [UNCONDITIONALLY] </command></para>
|
|
<para>You specify the name of the database that you would like to
|
|
stop in database-name, with the restriction that the database specified
|
|
cannot be the currently connected one. The "ON engine-name" clause
|
|
can be used only in Interactive SQL. You use it to specify the server
|
|
that the database is running on. Outside of Interactive SQL, the
|
|
database can only be stopped if it is on the current server. The
|
|
UNCONDITIONALLY keyword forces databases to be stopped, even if
|
|
there are connections to it. By default, you can't stop a database
|
|
if there are connections active. </para>
|
|
</sect2>
|
|
|
|
<sect2><title>Connecting to a database</title>
|
|
<para>You can connect to an Adaptive Server Anywhere database via
|
|
any of the following interfaces: </para>
|
|
<itemizedlist><listitem><para>ODBC </para></listitem>
|
|
<listitem><para>OLE DB or ADO </para></listitem>
|
|
<listitem><para>Embedded SQL </para></listitem>
|
|
<listitem><para>Sybase Open Client </para></listitem>
|
|
<listitem><para>JDBC </para></listitem></itemizedlist>
|
|
<para>Regardless of how you connect, you must specify some parameters,
|
|
such as a username and password, to establish a connection to the
|
|
database. These can be specified in a connection string, the SQLCONNECT
|
|
environment variable, an ODBC data source configuration, or the fields
|
|
of a dialog box. </para>
|
|
<para>In this section, you'll find explanations on how to connect
|
|
via SQL and ODBC. </para>
|
|
<para>As the Adaptive Server Anywhere network server is a client/server
|
|
database, you may connect to a Linux-hosted database from Windows-based
|
|
PCs and other non-Linux devices, as well as Linux applications.
|
|
Programming interfaces such as OLE DB or ADO are available ony on
|
|
Windows, but can still be used against a Linux-hosted database. </para>
|
|
|
|
<sect3><title>Connection strings</title>
|
|
<para>Connection strings are frequently used when performing actions
|
|
on a database. They consist of a list of parameter settings, delimited
|
|
by semicolons and enclosed in double quotes. There should be no
|
|
extra spaces in a connection string. </para>
|
|
<para>Example: </para>
|
|
<para><command>"uid=DBA;pwd=SQL"</command></para>
|
|
<para>The short strings of letters just before each equal sign (in
|
|
this example, uid, pwd, and dbf) are called <emphasis>keywords</emphasis>,
|
|
which each correspond to a connection parameter. There are many
|
|
connection parameters available, and they are listed in the Connecting
|
|
to a Database chapter of the Adaptive Server Anywhere User's Guide.
|
|
They are also described in detail in the Connection and Communication
|
|
Parameters chapter of the Adaptive Server Anywhere Reference. </para>
|
|
<para>When Adaptive Server Anywhere utilities are looking for connection
|
|
parameters, they check the SQLCONNECT environment variable for any
|
|
parameters that were left out of the connection string. If you're
|
|
putting connection parameters into the SQLCONNECT environment variable,
|
|
replace the equal signs with number (#) signs. In bash you would
|
|
use the following command: </para>
|
|
<para><command>SQLCONNECT='uid#DBA;pwd#SQL'</command></para>
|
|
<para>The single quotes are necessary in the above command because
|
|
semicolons can be used to separate bash commands. You can also use
|
|
double quotes. </para>
|
|
<para>To make SQLCONNECT available in subsequent shells, you'd need
|
|
to use "export SQLCONNECT" to export the SQLCONNECT variable to
|
|
the environment. You may also want to put these commands into your
|
|
.bash_profile (or .profile, if you're using another shell) if you
|
|
want the same connection parameters to be available each time you
|
|
log in. </para></sect3>
|
|
|
|
<sect3><title>Connecting from Interactive SQL</title>
|
|
<para>To connect to a database from Interactive SQL, go to the Command
|
|
menu, and choose "Connect...", then fill in the dialog box as appropriate. </para>
|
|
</sect3>
|
|
|
|
<sect3><title>Connecting via ODBC</title>
|
|
<para>ODBC (which stands for Open Database Connectivity) is an industry-standard
|
|
interface for connecting client applications to relational and non-relational
|
|
DBMSes. When you create an ODBC data source, it encapsulates the
|
|
data and any other information required to get the data, including
|
|
connection parameters. </para>
|
|
|
|
<sect4><title>Setting up ODBC with Adaptive Server Anywhere</title>
|
|
<para>To connect to Adaptive Server Anywhere from ODBC applications
|
|
on Linux, you can either use Sybase's ODBC driver as a driver manager,
|
|
or use a third-party ODBC driver manager such as iODBC or unixODBC.
|
|
If you choose the latter route, follow the installation instructions for
|
|
the driver manager you've chosen and choose dbodbc7.so (which resides
|
|
in the sybase/SYBSsa7/lib directory) as the ODBC driver for Adaptive
|
|
Server Anywhere. </para>
|
|
<para>If you choose the former route, you can use Adaptive Server
|
|
Anywhere's ODBC driver as a driver manager if you will only be connecting
|
|
to Adaptive Server Anywhere databases. To do so, you need to create
|
|
a few symbolic links so that ODBC driver manager requests get routed
|
|
to the Sybase ODBC driver. From the sybase/SYBSsa7/lib subdirectory,
|
|
enter the following commands: </para>
|
|
<para><command>$ ln -s dbodbc7.so libodbc.so</command></para>
|
|
<para><command>$ ln -s dbodbc7.so libodbc.so.1</command></para>
|
|
<para><command>$ ln -s dbodbc7.so libodbcinst.so</command></para>
|
|
<para><command>$ ln -s dbodbc7.so libodbcinst.so.1</command></para>
|
|
<para>That's it! </para></sect4>
|
|
|
|
<sect4><title>About ODBC data sources</title>
|
|
<para>Data sources exist on the client computer, with at least one
|
|
for each database accessible via ODBC. They reside in the .odbc.ini
|
|
file or in a separate .dsn file. </para>
|
|
<para>If the client computer is running Linux or another UNIX operating
|
|
system, ODBC data sources can be used both for ODBC applications
|
|
as well as for the Interactive SQL and Sybase Central utilities. </para>
|
|
<para>NOTE: The database server looks for <emphasis>.odbc.ini</emphasis> in
|
|
the following locations, among several others: </para>
|
|
<orderedlist><listitem><para>ODBCINI environment variable </para></listitem>
|
|
<listitem><para>ODBCHOME and HOME environment variables </para></listitem>
|
|
<listitem><para>The user's home directory </para></listitem>
|
|
<listitem><para>The current directory </para></listitem>
|
|
<listitem><para>The path </para></listitem>
|
|
<listitem><para>The root directory</para></listitem></orderedlist>
|
|
<para>If no .odbc.ini file exists in your home directory, you'll
|
|
have to create one in your home directory. You can check if one
|
|
exists by using the command "ls -a ~/.odbc.ini".</para>
|
|
<para>You manage ODBC data sources using the <emphasis>dbdsn </emphasis>command
|
|
line utility. </para>
|
|
<para>Syntax: </para>
|
|
<programlisting><command>dbdsn [ modifier-switches ]
|
|
{ -l
|
|
| -d dsn
|
|
| -g dsn
|
|
| -w dsn [details-switches]
|
|
| -cl }</command></programlisting>
|
|
<para>dbdsn has four main modes of operation, and its behaviour
|
|
depends on whether you choose the -l, -d, -g, or -w switch. Where
|
|
applicable, the name of the data source to be operated on is specified
|
|
by dsn. </para>
|
|
<itemizedlist><listitem><para>the -l switch lists the data sources
|
|
that have been defined </para></listitem>
|
|
<listitem><para>the -d switch deletes the specified data source</para></listitem>
|
|
<listitem><para>the -g switch gives you the details of the specified
|
|
data source</para></listitem>
|
|
<listitem><para>the -w switch creates a new DSN using parameters
|
|
specified in details-switches</para></listitem></itemizedlist>
|
|
<para>The most important details-switch is the -c switch, which
|
|
allows you to specify the usual database connection parameters.
|
|
You can also specify the name of a database server as a details-switch.
|
|
Type "dbdsn -cl" to display a list of available connection parameters. </para>
|
|
<para>To create a new data source named MyNewDSN for the server
|
|
MyServer, execute the following command at a shell prompt: </para>
|
|
<para><command>dbdsn -w MyNewDSN -c "uid=dba;pwd=sql;eng=MyServer" </command></para>
|
|
<para>If there is a data source named MyNewDSN already existing,
|
|
dbdsn asks if you would like to overwrite it. </para>
|
|
<para>Conversely, to delete MyNewDSN, execute the following command: </para>
|
|
<para><command>dbdsn -d MyNewDSN </command></para>
|
|
<para>The modifier-switches control how dbdsn outputs its messages
|
|
to screen, and whether or not data sources can be overwritten without
|
|
confirmation. For more information on other dbdsn options, see "The
|
|
Data Source utility" under the Database Administration Utilities
|
|
chapter of the Adaptive Server Anywhere Reference. </para></sect4>
|
|
|
|
<sect4><title>Connecting to an ODBC data source</title>
|
|
<para>Once you've created an ODBC data source, you can access it
|
|
through the DSN (DataSourceName) connection string keyword. </para>
|
|
<para>For an ODBC data source called mydatasrc, for example, use
|
|
the following connection string to connect to the database associated
|
|
with it: </para>
|
|
<para><command>"dsn=mydatasrc"</command></para>
|
|
<para>NOTE: Explicitly-provided connection parameters and SQLCONNECT
|
|
override any parameters provided in the ODBC data source, in that
|
|
order. </para>
|
|
<para>NOTE: The FileDSN connection parameter is not yet available
|
|
in version 7.0.2 of Adaptive Server Anywhere. Future versions of
|
|
Adaptive Server Anywhere should support File DSNs. </para>
|
|
</sect4>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="backup"><title>Backing up and Restoring a Database</title>
|
|
<para>Creating a backup of your data is a simple, essential component
|
|
of any serious installation. Adaptive Server Anywhere includes utilities
|
|
to help minimize data loss in case your data becomes corrupt as
|
|
a result of media failure, power outage, or other failure. </para>
|
|
|
|
<sect2><title>Creating a Backup of the Database</title>
|
|
<para>Backups of Adaptive Server Anywhere databases can be performed
|
|
through the dbbackup command line utility, SQL, or Sybase Central.
|
|
Both full backups and incremental backups can be performed, and
|
|
they can be performed either online or offline (that is, whether
|
|
the server is running or not, respectively). In addition, backups
|
|
can be performed both from the server side and from the client side.</para>
|
|
|
|
<sect3><title>Full vs. Incremental Backups</title>
|
|
<para>A full backup makes copies of the main database file and the
|
|
transaction log file. While it's the most basic and essential type
|
|
of backup, it usually isn't practical to regularly perform full backups
|
|
of large databases. As a result, incremental backups are commonly
|
|
used. </para>
|
|
<para>An incremental backup makes a copy of the transaction log
|
|
alone. It takes place as part of a cycle that begins with a full
|
|
backup, which is then followed by a given number of incremental backups.
|
|
Since only the transaction log is copied, an incremental backup
|
|
uses less time and resources, making it particularly suited for
|
|
large databases. Keep in mind, though, that the more time you leave
|
|
between full backups, the greater the risk of losing data in the
|
|
event that one of the transaction logs becomes unusable. </para></sect3>
|
|
|
|
<sect3><title>Online vs. Offline Backups</title>
|
|
<para>An online backup is performed without stopping the database
|
|
server. It provides a consistent snapshot of the database, even
|
|
as the database is modified. Online backups are useful for databases
|
|
with high availability requirements, but they won't complete until
|
|
all active transactions are complete. </para>
|
|
<para>In contrast, offline backups are performed once the database
|
|
server has been shut down. They're useful for when the database
|
|
can be taken down on a regular basis. You make offline backups simply
|
|
by copying the pertinent files to another location using the cp
|
|
command in a terminal window. </para>
|
|
<para>In either case, both full and incremental backups can be performed. </para>
|
|
</sect3>
|
|
|
|
<sect3><title>Server-side vs. Client-side Backups</title>
|
|
<para>An online backup can be performed from a client using the <emphasis>dbbackup</emphasis> command
|
|
line utility. This is known as a client-side backup, and it puts
|
|
a backup of the database on the client machine. </para>
|
|
<para>An online backup can also be performed on the server by issuing
|
|
the BACKUP statement in SQL. Server-side backups are generally faster,
|
|
owing to the fact that client-side backups usually depend upon transport
|
|
across networks. </para></sect3>
|
|
|
|
<sect3><title>How to make a backup</title>
|
|
<sect4><title>From the command line</title>
|
|
<para>The command line utility for making a backup of your database
|
|
is <emphasis>dbbackup</emphasis>. Its syntax is as follows: </para>
|
|
<para><command>dbbackup [ switches ] directory</command></para>
|
|
<para>directory specifies a destination directory for the backup
|
|
files. Some useful switches include the following: </para>
|
|
<itemizedlist><listitem><para>-c is used to specify a connection
|
|
string to the database to be backed up </para></listitem>
|
|
<listitem><para>-d creates a backup of the main database file only </para></listitem>
|
|
<listitem><para>-t creates a backup of the transaction log only </para></listitem>
|
|
<listitem><para>-r renames any previous transaction log backups
|
|
and creates a new one. It is necessary for replication systems. </para></listitem>
|
|
<listitem><para>-x deletes any previous transaction log backups
|
|
and creates a new one. It should not be used in replication systems. </para></listitem></itemizedlist>
|
|
<para>For example, if you were creating your first backup, you would
|
|
want to create a full backup of MyDatabase. To put it in ./backups,
|
|
use the following command: </para>
|
|
<para><command>dbbackup -c "uid=DBA;pwd=SQL;dbn=MyDatabase" ./backups</command></para>
|
|
<para>The next few backups could be incremental backups, so use
|
|
the following: </para>
|
|
<para><command>dbbackup -t -r -c "uid=DBA;pwd=SQL;dbn=MyDatabase" ./backups</command> </para></sect4>
|
|
<sect4><title>From SQL</title>
|
|
<para>If you prefer to back up your database from Interactive SQL,
|
|
the SQL statement is BACKUP DATABASE. You must have DBA authority
|
|
to use BACKUP DATABASE, whose syntax is as follows: </para>
|
|
<programlisting><command>BACKUP DATABASE DIRECTORY backup-directory
|
|
[ WAIT BEFORE START ]
|
|
[ DBFILE ONLY ]
|
|
[ TRANSACTION LOG ONLY ]
|
|
[ TRANSACTION LOG RENAME [ MATCH ] ]
|
|
[ TRANSACTION LOG TRUNCATE ]</command></programlisting></sect4>
|
|
<sect4><title>From Sybase Central</title>
|
|
<para>To make a backup from Sybase Central, open the Utilities folder
|
|
under "Adaptive Server Anywhere 7" and double-click "Backup Database"
|
|
to open a dialog box which will guide you through the backup process. </para>
|
|
</sect4></sect3></sect2>
|
|
|
|
<sect2><title>Validating the database and its backup</title>
|
|
<para>You should regularly use either Sybase Central, SQL, or the
|
|
dbvalid command line utility to validate a backup of your database
|
|
in read-only mode, and, if errors are found, make repairs against
|
|
the original database. <emphasis>Never</emphasis> make changes to
|
|
a backup database! To read more about validation, see "Validating
|
|
a database" and "Validating a transaction log" under the Backup
|
|
and Data Recovery chapter of the Adaptive Server Anywhere User's
|
|
Guide. </para></sect2>
|
|
|
|
<sect2><title>Recovering the database</title>
|
|
<para>Depending on the way your database and its backups are set
|
|
up, and the status of your files after a media failure, there are
|
|
several possible processes involved in how you go about recovering
|
|
data. For information on how to recover data in various situations,
|
|
see the Backup and Data Recovery chapter of the Adaptive Server
|
|
Anywhere User's Guide. </para></sect2>
|
|
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="manage"><title>Managing a Database</title>
|
|
<sect2><title>Tables</title>
|
|
<para>All data in relational databases is held in tables. Each column
|
|
is assigned a data type, and each row of a table holds a value for
|
|
each column. The following are true for any table in a relational
|
|
database: </para>
|
|
<itemizedlist><listitem><para>There is no significance to the order
|
|
of rows and columns. </para></listitem>
|
|
<listitem><para>Each row contains exactly one value per column. </para></listitem>
|
|
<listitem><para>All values in a column are of the same type. </para></listitem></itemizedlist>
|
|
<para>Here are some things to keep in mind when designing your database: </para>
|
|
<itemizedlist><listitem><para>give every table a primary key </para></listitem>
|
|
<listitem><para>make sure that each table holds information about
|
|
one specific entity </para></listitem>
|
|
<listitem><para>foreign keys form the relationships between tables
|
|
(and therefore entities) </para></listitem></itemizedlist>
|
|
|
|
<sect3><title>Creating a Table</title>
|
|
<para>When you first create a database in Adaptive Server Anywhere,
|
|
the only tables it contains are the system tables. To create tables
|
|
to hold your data, use either the CREATE TABLE statement in SQL
|
|
or the Sybase Central Table Editor. You must have the DBA or RESOURCE
|
|
authority to create a table, and you must have the DBA authority
|
|
make another user its owner. </para>
|
|
<para>The CREATE TABLE statement has an extremely broad range of
|
|
options that are documented in the Adaptive Server Anywhere Reference,
|
|
so only a small subset of options are described here. The basic
|
|
syntax is as follows: </para>
|
|
<programlisting><command>CREATE TABLE owner.table-name
|
|
(column-name datatype [, column-name datatype]...)</command></programlisting>
|
|
<para>The "owner." portion before tablename is optional, and is
|
|
used by a user with the DBA authority to make another user the owner
|
|
of the new table. table-name and column-name, respectively, are
|
|
the names of the table and its columns. Insert the words PRIMARY
|
|
KEY after datatype to make it the primary key. </para>
|
|
<para>See the SQL Data Types chapter of the Adaptive Server Anywhere
|
|
Reference for a list of the types available and their characteristics. </para>
|
|
<para>To create a table named customer with columns id, name, address,
|
|
city_state_zip, and phone, with id as the primary key, for example,
|
|
use the following CREATE TABLE statement: </para>
|
|
<programlisting><command>create table customer
|
|
(id integer not null primary key,
|
|
name char ( 35 ),
|
|
address char ( 35 ),
|
|
city_state_zip char ( 35 ),
|
|
phone char ( 12 )
|
|
) </command></programlisting>
|
|
<para>It's also important to add "not null" in the case of id, since
|
|
it's the primary key. </para>
|
|
<para>To create a table in Sybase Central, connect to your database
|
|
and open its Tables folder. If you double-click "Add Table," Sybase
|
|
Central Table Editor will be opened and using the button bar, you
|
|
can set up the table as you wish. Hover the mouse pointer over each
|
|
button to find out what it does. Don't forget to make a primary
|
|
key before you close the Table Editor! </para>
|
|
<para>Some table creation options documented in the Adaptive Server
|
|
Anywhere Reference but not here that you might be interested in
|
|
include automatic incrementation (often used on the primary key),
|
|
constraints, and foreign keys. </para></sect3>
|
|
|
|
<sect3><title>Making Alterations to Tables</title>
|
|
<para>You can make many kinds of changes to a table once it's been
|
|
created. Some of the things you can do include the following: </para>
|
|
<itemizedlist><listitem><para>rename a table </para></listitem>
|
|
<listitem><para>add, remove, or rename columns </para></listitem>
|
|
<listitem><para>change the datatype, default value, or length of
|
|
a column </para></listitem></itemizedlist>
|
|
<para>As with creating tables, you can alter them through SQL or
|
|
Sybase Central. To alter a table in SQL, you use the ALTER TABLE
|
|
statement. ALTER TABLE has a great variety of options, which are
|
|
described in detail in the Adaptive Server Anywhere Reference. You'll
|
|
see a few basic examples here just to get you started. </para>
|
|
<para>To rename the customer table to cust: </para>
|
|
<programlisting><command>alter table customer
|
|
rename cust</command></programlisting>
|
|
<para>To add a company_name column to cust, with a maximum length
|
|
of 35 characters: </para>
|
|
<programlisting><command>alter table cust
|
|
add (company_name char (35) )</command></programlisting>
|
|
<para>To give company_name a default value of "n/a" : </para>
|
|
<programlisting><command>alter table cust
|
|
alter company_name set default 'n/a'</command></programlisting></sect3>
|
|
</sect2>
|
|
|
|
<sect2><title>Users, permissions, and authorities</title>
|
|
<para>NOTE: Before putting an Adaptive Server Anywhere database
|
|
into serious usage, your first order of business as the database
|
|
administrator (DBA) should be to change the DBA password from the
|
|
default password, "SQL." For details on how to do this, see section
|
|
6.2.5. </para>
|
|
<para>This section describes the user IDs that are created for each
|
|
database, briefly describes how to create new user IDs, and goes
|
|
over some of the ways you can use user IDs to control outsiders
|
|
access of data. For more information on user IDs, groups, and permissions,
|
|
see the Managing User IDs and Permissions chapter of the Adaptive
|
|
Server Anywhere User's Guide. </para>
|
|
|
|
<sect3><title>User IDs</title>
|
|
<sect4><title>Special user IDs</title>
|
|
<para>When Adaptive Server Anywhere databases are initialized, two
|
|
groups and two user IDs are created. The two groups created are
|
|
SYS and PUBLIC. The two user IDs created are DBA and dbo.</para>
|
|
<para>SYS is a user as well as a group, but no one can connect to
|
|
the database using the user ID SYS. SYS owns the system tables and
|
|
the system views, and only SYS can update the system tables.</para>
|
|
<para>PUBLIC is a member of the SYS group, and has only SELECT permissions
|
|
on most system tables and system views. Since new user IDs are,
|
|
by default, members of PUBLIC, you should revoke PUBLIC's membership
|
|
in SYS if you want new users to have no permissions by default.</para>
|
|
<para>The DBA user can directly modify any part of an Adaptive Server
|
|
Anywhere database except the system tables. This is why it's important
|
|
to change the default DBA password from "SQL." You should be cautious
|
|
when giving DBA authority to a user (see the DBA Authority section
|
|
below). If a user needs DBA authority, s/he should be given DBA
|
|
authority, rather than the DBA's password. </para></sect4>
|
|
|
|
<sect4><title>Creating new user IDs</title>
|
|
<para>The SQL statement to add a new user ID is GRANT CONNECT. </para>
|
|
<para>Syntax: </para>
|
|
<programlisting><command>GRANT CONNECT TO userid1
|
|
IDENTIFIED BY password1 </command></programlisting>
|
|
<para>To add a user ID with the name Mortimer, execute the following
|
|
SQL statement: </para>
|
|
<programlisting><command>grant connect to mortimer identified by
|
|
monkey </command></programlisting></sect4>
|
|
</sect3>
|
|
|
|
<sect3><title>Permissions</title>
|
|
<para>This section explains permissions on tables that can be granted
|
|
to users. Permissions are granted on a user-by-user basis. </para>
|
|
<para>There are a few different table permissions that can be granted
|
|
to a user, and they are each granted separately. </para>
|
|
<itemizedlist><listitem><para><emphasis>SELECT</emphasis> allows
|
|
the user to <emphasis>read</emphasis> data, and can be restricted
|
|
to particular columns. </para></listitem>
|
|
<listitem><para><emphasis>INSERT</emphasis> allows the user to <emphasis>add</emphasis> data. </para></listitem>
|
|
<listitem><para><emphasis>UPDATE</emphasis> allows the user to <emphasis>change</emphasis> data,
|
|
and can be restricted to particular columns. </para></listitem>
|
|
<listitem><para><emphasis>DELETE</emphasis> allows the user to <emphasis>remove</emphasis> data. </para></listitem>
|
|
<listitem><para><emphasis>ALTER</emphasis> allows the user to <emphasis>modify
|
|
the structure</emphasis> of a table. </para></listitem>
|
|
<listitem><para><emphasis>REFERENCES</emphasis> allows the user
|
|
to add indexes, primary keys, and foreign keys. </para></listitem>
|
|
<listitem><para><emphasis>ALL</emphasis> includes all the above
|
|
permissions. </para></listitem></itemizedlist>
|
|
<para>With the exceptions of ALTER and REFERENCES, which apply to
|
|
tables exclusively, the table permissions apply to both tables and
|
|
views. The SQL syntax for granting permissions is as follows: </para>
|
|
<programlisting><command>GRANT [ SELECT (column-name, ...)
|
|
| INSERT
|
|
| UPDATE (column-name, ...)
|
|
| DELETE
|
|
| ALTER
|
|
| REFERENCES
|
|
| ALL ]
|
|
ON table-name
|
|
TO userid</command></programlisting>
|
|
<para>The user userid is given the specified permission(s) on the
|
|
table identified by table-name. If the permissions granted include
|
|
SELECT and/or UPDATE, they are granted only on the columns specified
|
|
in column-name. </para>
|
|
<para>Let's say a list of available banana types is stored in the
|
|
type and quantity columns of a table named banana_supply. To allow
|
|
Mortimer to see a list of available banana types along with their
|
|
quantities, use the following SQL statement: </para>
|
|
<para><command>grant select on banana_supply (type, quantity) to mortimer</command></para>
|
|
<para>When you grant a permission to a user, you have the option
|
|
of granting him the ability to grant that same permission to others.
|
|
To grant a user the permission to do so, add WITH GRANT OPTION to
|
|
the end of your users GRANT statement when you're granting them
|
|
their permissions. </para>
|
|
<para>To allow Mortimer to see a list of banana types available
|
|
along with the quantities of each, as well as allowing him to grant
|
|
others the same SELECT permission, use this SQL statement: </para>
|
|
<programlisting><command>grant select on banana_supply (type, quantity)
|
|
to mortimer
|
|
with grant option </command></programlisting></sect3>
|
|
|
|
<sect3><title>Authorities</title>
|
|
<para>An authority is a different level of permission. There are
|
|
two types of authority. </para>
|
|
|
|
<sect4><title>RESOURCE authority</title>
|
|
<para>A user with the RESOURCE authority can create and drop database
|
|
objects such as tables, views, stored procedures, and functions.
|
|
The RESOURCE authority also allows the user to create and remove
|
|
user IDs and passwords. To give userid the RESOURCE authority, execute
|
|
the following SQL statement: </para>
|
|
<para><command>GRANT RESOURCE TO userid </command></para></sect4>
|
|
<sect4><title>DBA authority</title>
|
|
<para>A user with the DBA authority can perform any database operation,
|
|
and automatically has all permissions on all tables, except the
|
|
system tables. The DBA can create and remove user IDs and passwords,
|
|
grant RESOURCE and DBA authority, and unload and reload the database. </para>
|
|
<para><command>GRANT DBA TO userid </command></para></sect4></sect3>
|
|
|
|
<sect3><title>Removing Users and Revoking Permissions</title>
|
|
<para>The SQL statement to delete a user ID is REVOKE CONNECT. </para>
|
|
<para>Syntax: </para>
|
|
<para><command>REVOKE CONNECT FROM userid [, userid ] </command></para>
|
|
<para>As suggested by the portions in square parentheses, it's possible
|
|
to remove multiple user IDs in a single statement. For example,
|
|
to remove the user IDs for Mortimer and Chestington, execute this
|
|
statement: </para>
|
|
<para><command>revoke connect from mortimer, chestington</command></para>
|
|
<para>To revoke permissions or authorities given to a particular
|
|
user, you take the original granting statement, replace the GRANT
|
|
with REVOKE, and replace the TO with FROM. To take away Mortimer's
|
|
permission to view the banana_supply table, for example, use this
|
|
REVOKE statement: </para>
|
|
<para><command>revoke select on banana_supply (type, quantity) from
|
|
mortimer</command></para></sect3>
|
|
|
|
<sect3><title>Changing Passwords</title>
|
|
<para>To change the password associated with a particular user ID,
|
|
use a GRANT CONNECT statement again: </para>
|
|
<para><command>GRANT CONNECT TO userid IDENTIFIED BY newpassword</command></para>
|
|
<para>For example, to change the DBA's password from "SQL" to "d0n13xw9,"
|
|
use this statement: </para>
|
|
<para><command>grant connect to DBA identified by d0n13xw9</command></para></sect3>
|
|
</sect2>
|
|
|
|
<sect2><title>Making the database more secure</title>
|
|
<para>Some of the Adaptive Server Anywhere features you may wish
|
|
to use in building a secure environment for your data include the
|
|
following: </para>
|
|
<itemizedlist><listitem><para><emphasis>User identification and
|
|
authentication </emphasis>control access to databases.</para></listitem>
|
|
<listitem><para><emphasis>Permissions and authorities</emphasis>,
|
|
which have already been explained in previous sections, control
|
|
the actions a user can carry out while connected to a database. </para></listitem>
|
|
<listitem><para><emphasis>Views and stored procedures </emphasis>allow
|
|
you to carefully tune the data a user can access and the operations
|
|
a user can execute. </para></listitem>
|
|
<listitem><para><emphasis>Connection encryption</emphasis> can prevent
|
|
unauthorized persons from snooping. </para></listitem></itemizedlist>
|
|
<para>Some of these features have already been mentioned in this
|
|
HOWTO, and some of them will be elaborated upon in the following
|
|
sections. While the concepts of triggers, procedures, and views
|
|
will be introduced so you can decide if and how you'll use them,
|
|
their implementation won't be discussed. You can find indepth information
|
|
on them, as well as details on their implementation, in the sections
|
|
of the Adaptive Server Anywhere User's Guide listed below: </para>
|
|
<table colsep = "1" frame = "all" rowsep = "1"><title></title><tgroup
|
|
cols = "2" colsep = "1" rowsep = "1">
|
|
<colspec colname = "1" colnum = "1" colwidth = "3.417in">
|
|
<colspec colname = "2" colnum = "2" colwidth = "5.333in">
|
|
<tbody>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>Chapter</emphasis></entry>
|
|
<entry colname = "2" valign = "top">Section</entry>
|
|
</row>
|
|
<row rowsep = "1">
|
|
<entry colname = "1" valign = "top"><emphasis>Using Procedures,
|
|
Triggers, and Batches</emphasis></entry>
|
|
<entry colname = "2" valign = "top">Benefits of procedures and triggers</entry>
|
|
</row>
|
|
<row rowsep = "0">
|
|
<entry colname = "1" valign = "top"><emphasis>Managing User IDs
|
|
and Permissions</emphasis></entry>
|
|
<entry colname = "2" valign = "top">Using views and procedures for
|
|
extra security</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup></table>
|
|
|
|
<sect3><title>Increasing password security</title>
|
|
<para>By default, passwords can be any length. For greater security,
|
|
you can enforce a minimum length on all new passwords, to make them
|
|
more difficult to guess. You do this by setting the MIN_PASSWORD_LENGTH
|
|
database option to a greater value. The following statement enforces
|
|
a minimum password length of 8 characters: </para>
|
|
<para><command>set option public.min_password_length = 8 </command></para>
|
|
<para>Check the "Changing Passwords" section of this document to
|
|
learn how to change a user's password, and don't forget to change
|
|
the DBA's password! </para></sect3>
|
|
|
|
<sect3><title>Views, procedures, and triggers</title>
|
|
<para>Views are useful when it is appropriate to give a user access
|
|
to just one portion of a table. The portion can be defined in terms
|
|
of rows or in terms of columns. For example, you may wish to prevent
|
|
a group of users from seeing the quantity column of the banana_supply
|
|
table, or you may wish to limit a user to see information on a particular
|
|
type of banana. </para>
|
|
<para>While views restrict access based on the data, procedures
|
|
and triggers restrict access based on the actions a user can take.
|
|
Procedures and triggers store SQL statements in a database for use by
|
|
all applications. They execute under the table permissions of the
|
|
associated table's owner, regardless of the permissions of the user
|
|
who either executes the procedure or fires the trigger. </para>
|
|
<para>Procedures are invoked by a CALL statement, and can take values
|
|
as well as return them. Unlike procedures, however, triggers are
|
|
can neither take values nor return them, and are invoked by insertions,
|
|
updates, or deletions in the table it is associated with. Permissions
|
|
are not associated with triggers. They execute when the action defined
|
|
to fire them is performed, regardless of the user.</para>
|
|
<para>For strict security, you can prevent all access to the tables,
|
|
and grant permission to users to execute certain stored procedures
|
|
that carry out specific tasks. This approach strictly defines the manner
|
|
in which the database can be modified. </para></sect3>
|
|
|
|
<sect3><title>Encrypting client/server communications</title>
|
|
<para>Encrypting client/server communications prevents third parties
|
|
from reading messages being sent between the client and the server.
|
|
It can be enabled from either the server side or the client side.
|
|
To enable encryption from the server, use the -e option at server
|
|
startup. For example, use the following command to start up the
|
|
database server to accept encrypted connections to mydb.db over
|
|
TCP/IP: </para>
|
|
<para><command>dbsrv7 -e -x tcpip mydb.db </command></para>
|
|
<para>To enable encryption from a particular client, use the ENC
|
|
keyword in the connection string. For example, to encrypt a connection
|
|
over TCP/IP to mydb.db, your connection string would appear as follows: </para>
|
|
<para><command>"uid=mortimer;pwd=monkey;links=tcpip;eng=MyServer;dbf=mydb.db;enc=true"</command></para>
|
|
<para>For more information about client/server communications encryption,
|
|
look for the -e command-line option under "The database server"
|
|
in the Adaptive Server Anywhere Reference Manual, and for "Encryption
|
|
connection parameter" under "Connection parameters" . </para></sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="moreinfo"><title>Where to get more information</title>
|
|
<para><emphasis>On-line help</emphasis> is available on your cdrom.
|
|
If your computer is set up to mount the CD-ROM to /mnt/cdrom/ the
|
|
help is located in /mnt/cdrom/help/contents.htm. Open it with Netscape
|
|
Navigator, or any other web browser that supports tables. Style
|
|
sheets support is recommended, but not necessary. </para>
|
|
<para id = "Asa-7htmlhlt510857588">A <emphasis>FAQ</emphasis> is
|
|
available for the UNIX version of Adaptive Server Anywhere at <ulink url="http://www.sybase.com/detail/1,3693,1011965,00.html">http://www.sybase.com/detail/1,3693,1011965,00.html</ulink> </para>
|
|
<para>Check if there have been any <emphasis>bug fixes</emphasis> or <emphasis>updates</emphasis> posted
|
|
at <ulink url="http://downloads.sybase.com/swx/sdmain.stm">http://downloads.sybase.com/swx/sdmain.stm</ulink>. </para>
|
|
<para><emphasis>Newsgroups</emphasis> can be read from the web or
|
|
with a news reader. The newsgroups sybase.public.sqlanywhere.general<emphasis> </emphasis>and<emphasis> </emphasis>sybase.public.sqlanywhere.linux<emphasis> </emphasis>are
|
|
most likely to be relevant. To view newsgroups on the web, visit
|
|
<ulink url="http://www.sybase.com/support/newsgroups">http://www.sybase.com/support/newsgroups</ulink>.
|
|
Be sure to search old
|
|
threads for similar problems. It may already have been resolved. </para>
|
|
</sect1>
|
|
|
|
<sect1 id="legal"><title>Legalities and Acknowledgements</title>
|
|
<sect2><title>Copyright and Licenses</title>
|
|
<para>Copyright (c) 2001 Sybase Inc.</para>
|
|
<para>This manual may be reproduced in whole or in part, without
|
|
fee, subject to the following restrictions:</para>
|
|
<itemizedlist><listitem><para>The copyright notice above and this
|
|
permission notice must be preserved complete on all complete or
|
|
partial copies.</para></listitem>
|
|
<listitem><para>Any translation or derived work must be approved
|
|
by the author in writing before distribution.</para></listitem>
|
|
<listitem><para>If you distribute this work in part, instructions
|
|
for obtaining the complete version of this manual must be included,
|
|
and a means for obtaining a complete version provided.</para></listitem>
|
|
<listitem><para>Small portions may be reproduced as illustrations
|
|
for reviews or quotes in other works without this permission notice
|
|
if proper citation is given. Exceptions to these rules may be granted
|
|
for academic purposes: Use the contact information in the next section to
|
|
ask. These restrictions are here to protect us as authors, not to
|
|
restrict you as learners and educators. Any source code (aside from
|
|
the DocBook this document was written in) in this document is placed
|
|
under the GNU General Public License, available via anonymous FTP from
|
|
the GNU archive.</para></listitem></itemizedlist>
|
|
<para>The preceding notice was borrowed and tweaked from the LDP
|
|
Author Guide's copyright notice.</para></sect2>
|
|
|
|
<sect2><title>Names and Contacts</title>
|
|
<para>This document was initiated by Michael Moller and (mostly)
|
|
written by Aylwin Lo with assistance from Michael Heal and Tom Slee.
|
|
We work at Sybase.</para>
|
|
<para>Since the author is a co-op student, the best way to contact
|
|
someone regarding this document is by posting to the sybase.public.sqlanywhere.linux
|
|
newsgroup, available on the forums.sybase.com news server.</para></sect2>
|
|
|
|
<sect2><title>Acknowledgement</title>
|
|
<para>Thanks to the folks at <ulink url="http://www.commandprompt.com/">http://www.commandprompt.com/</ulink> for getting
|
|
the text of this HOWTO into workable SGML for us.</para></sect2>
|
|
</sect1>
|
|
|
|
</article>
|