Introduction to Sybase, Part 1: Setting Up the Server

From Issue #62 June 1999 Jun 01, 1999 By Jay Sissom in

Software

Sybase comes to Linuxhere's how it works. Sybase has released their SQL Database product for Linux. This is a port of their full commercial database productit is not crippled in any way. This series of articles will describe how to install and configure the server and how to set up and use clients. It would be impossible to teach everything about developing and maintaining clientserver applications in a short series of articles, but these should get you started. What is the Sybase SQL Server? The Sybase SQL Server is an industrial-strength client-server database engine. It manages data and allows many clients to access this data efficiently and securely. The Sybase SQL Server allows you to concentrate on writing your application rather than on writing data access and security code. Installing the Sybase SQL Server Before installing the server, you must determine if your system can handle it. The server with all the documentation will require approximately 180MB of disk space plus space for your databases. A running server will take a minimum of 21MB of RAM. If you have many clients, you should give your server much more RAM; so for small development systems, a minimum of 32MB is required. For small-scale production servers, I would suggest a minimum of 64MB of RAM. As usual, the more RAM you give it, the faster it runs. I have installed the server on numerous Red Hat 5.1 systems, as it requires the newer glibc libraries. If you have an older Linux installation that does not include the glibc

libraries (Red Hat 4.2 and below), you should upgrade your system. If you have a non-Red Hat system, you will also need an RPM tool to install the files. The server is distributed as two RPM files. According to the Sybase Linux web page (http://linux.sybase.com/), you can install the server only on Red Hat Linux 5.x and Caldera OpenLinux 1.3. In my opinion, you could install it on any Linux systemit would just be a bit more difficult than if you are using the Red Hat or Caldera version. The web URL to access these files is http://linux.sybase.com/. This site will point you to one of the sites that offers the files for download. Remember this siteit contains important information you will need when using your SQL Server. After entering your registration information, you will be able to download two RPM files: one containing the Sybase SQL Server, the other with documentation in HTML and PostScript. This is approximately 40MB of data, so if you have a slow Internet connection, be prepared to wait a while. Fortunately, installing the software will take much less time than downloading it. To install the server, log in to your Linux system as root and type the following command:
rpm -i sybase-ase-11.0.3.3-1.i386.rpm

You will be asked to read the license agreement; then it will install the Sybase server to the /opt/sybase directory. On my system, this is a problem because I usually don't have enough space on the partition to hold /opt/sybase, so I make a link that redirects /opt to /usr/local before installing. This works because it doesn't matter where the software is installedit will work from any directory. From now on, I'll assume you have installed the server in its default location. During the installation, you will be asked to create a group named sybase and a user named sybase. You will use the sybase user to perform maintenance on the database server. All users who need access to the Sybase server should be members of the group named sybase. Now install the documentation files by running the following command:
rpm -i sybase-doc-11.0.3.3-1.i386.rpm

One thing the installation does not do is set the owner of the files correctly. While you are still logged in as root, issue the following command:
chown -R sybase:sybase /opt/sybase

Configuring the Sybase Server Now that all the files are installed on your system, it is time to configure an SQL server and a backup server. A backup server is used to back up data in the SQL server while the SQL server is running. It guarantees that when restored, your database will have the proper integrity. Copying your database files from the operating system will not guarantee that your database tables will be restored properly.

A single host can have multiple SQL servers if necessary. I would not recommend doing so, but it is an option. For our example, we will configure a single SQL server and a single backup server on our host. Log in as the user sybase using the password you set when installing the SQL server. Since it is your first login as the sybase user, the login script will ask if you would like to run sybinit. The sybinit program is used to configure new and existing Sybase servers and is located in the /opt/sybase/install directory. If you installed the documentation, you can follow along with the installation by using your browser and accessing the file /opt/sybase/doc/howto/howto-ase-quickstart.html. There isn't room in the magazine to display all the screens you will see. These screens are documented in the Quickstart Guide that comes with the server. The first option you should pick is option 3, Configure a Server product. Configure the SQL Server first by selecting option 1. Since this is a new server, select option 1 again. Each server should have a unique name. I recommend naming the server based on its function. For example, a production decision support server could be named dss_prod. A development accounting server could be named acctng_dev. For this example, name the server linux_dev. When you finish filling in the data for a screen, press ctrl-A to save your data. Press ctrl-A now. At this point, nine more steps are required to configure this SQL server. Select option 1. The interfaces file tells Sybase products where servers are located. Each server will listen on a specific port on its host. Just like SMTP mail, TELNET and web services, Sybase servers need a unique port to allow network connections. The interface file will hold the server name, host name and port number for each sybase server on your network. Select option 3 to add the port information for the linux_dev server. The sybinit program will automatically fill in the host name for your host. You should specify the TCP/IP port your server will listen on. For this example, select option 2, then specify 2360 as the port number. Any unused port will work. Press ctrl-A to save this entry in the interfaces file. After you confirm that everything is correct, press ctrl-A again. If you have multiple sybase servers that you access, you can add information for each server into your interfaces file. Before continuing, a little background information will be helpful. Database tables will hold the data for your application. For example, an accounts payable application would have an invoice table, a vendor table and a payment table. A database can hold many tables. A Sybase server will have multiple databases. An accounting application might have general ledger, accounts payable and accounts receivable databases. When a server is installed, it will have four databases:

master: The master database holds configuration data for the entire server. model: The model database is the basis for all new databases created on the server. sybsystemprocs: The sybsystemprocs database holds stored procedures used to maintain the server.

tempdb: The tempdb database is a temporary workspace used when processing queries.

The sybase server manages disk space in devices. A device is a pre-allocated file of a specific size. A device file can be up to 2GB. A single server can have many devices. Databases are created on devices. Select option 2. The master device holds the master database, the model database and the tempdb database. Its default size is 21MB. You can move the location of this file if you wish. If you have enough disk space, you can leave it in its current location. Press ctrl-A to save this screen. The sybinit program will give you a warning about the file name you selected. This is normal; on Linux, it will always give this warning. On other UNIX operating systems, the Sybase server devices should be raw partitions on the disk. This isn't possible on the current version of Linux, so we have to put our devices in operating system files. Select option 3. The sybsystemprocs database contains stored procedures used to maintain the server. This database can also be used to store any procedures you write for server maintenance. I recommend you double the size of this database, so that you can add additional stored procedures to your server. When you do this, you have to select option 5 to increase the size of the device before you select option 1 to increase the size of the database. Put 32MB for options 5 and 1. You can leave the rest of the options as they are, unless you would like to place the device file in a different location. Press ctrl-A to save this screen. Select option 4. As the server runs, it writes error messages to a text log file. This screen lets you set the location and name of this file. I recommend you give this file the same name as the database server. Change option 1 to /opt/sybase/install/linux_dev.log. Press ctrl-A to save this screen. Select option 5. The database server needs to know the name of its backup server. I always give the backup server the same name as the database server, with _bs on the end. Change option 1 to linux_dev_bs. Press ctrl-A to save this screen. Select option 6. The server can use many languages. I have never used anything other than us_english, so I can't tell you what will happen when choosing another language. For our example, just press ctrl-A to save the default for this screen. Select option 7. You can configure which character set to use when communicating between a client and the server. Each client will tell the server which character set it should use. If you do not know for sure that you need another character set, you should accept the defaults for this screen. Press ctrl-A to save this screen. Select option 8. Here you can specify which order to use when sorting data. By default, the server uses a binary order when sorting. This is the fastest sort method; however, when sorting words that are upper and lower case, the server uses the ASCII character set to sort so that uppercase letters are sorted before lowercase letters. Change the sort order to the dictionary sort order so that words are sorted properly regardless of case. Press ctrl-A.

Select option 9. If you wish, you can have the server maintain auditing information about users. For our example, we won't install auditing. Press ctrl-A to configure the server to not maintain auditing records. We have now told the sybinit program everything it needs to know to configure your SQL server. Press ctrl-A to save your configuration. The sybinit program will now configure your SQL server. It will warn you about the master device file again, but it will create the devices and prepare the server for use. Your new SQL database server is now running on your system. Press ctrl-A to go to the previous screen. The next step is to configure a new backup server. Select option 2, then option 1 to configure a new backup server. The name of the backup server should be linux_dev_bs. Press ctrl-A to save the backup server name. I recommend changing the name of the backup server log file to /opt/sybase/install/linux_dev_bs.log. This server needs to be specified in the interfaces file also. It will listen on its own unique port. Select option 2. Select option 3 to add a new listener. As before, the host name has already been specified. Change option 2 to 2361. This will be the port for the backup server. Press ctrl-A to save this screen. Press ctrl-A again to write this entry in the interfaces file. Everything else should be correct, so press ctrl-A to save this screen. The sybinit program will now configure the backup server and start it for you. Both the SQL server and the backup server should now be running on your host. We are almost done, but there are three steps we need to finish. Press ctrl-A to go to the previous screen. Select option 4, Configure an Open Client/Server Product. These three products should be configured before you use them. To be honest, I don't know what configuring these products does because no options are available and they seem to work before configuring; however, it can't hurt to follow the directions. Select each of the three options one after the other to configure them. When you are finished, press ctrl-A to leave this screen. Press ctrl-A again to leave the sybinit program. All of your entries are recorded in a log file. If you are configuring a production system, print this log file and keep it on hand in case you need to recreate the server that crashed at two in the morning. Testing the Server There is a basic client that comes with the Sybase SQL Server. This program is called isql. It is an interactive SQL program that allows you to enter SQL commands to the server and see the results. At the command line, type:
isql -Usa -Slinux_dev

The -U option tells the isql program which user name to use; sa is the system administrator account. It is similar to root on Linux. It has all rights in the server. The -S option specifies to which server to connect. In our case, the server name is linux_dev. The isql program will ask you for a password. Right after an installation,

the sa user does not have a password, so just press enter. You can now enter SQL commands that will run on your SQL server. The first command to run is a stored procedure that lets you change the password of a user. At the 1> prompt, type
sp_password null,'

sp_password is the name of the stored procedure. The sa user has no password, so we pass null as the first parameter. This parameter should be the password of the current user. The second parameter is the new password; put this password in quotes. At the 2> prompt, type:
go

go tells the isql program to execute the command. If you make a mistake while typing a command before typing go, you can type reset to erase the command and try again. All of the configuration information for the SQL server is stored in tables in the master database. Type the following:
1> select name from sysdatabases 2> go

This is an SQL command that queries the sysdatabases table. It will list the names of all the databases in your server. Almost all of the configuration information for the SQL server is stored in database tables. The documentation will give you more information on these tables. To quit the isql program, type quit at the 1> prompt. The SQL server comes with a script that will install an example database on your server. To install this database, type the following command at the $ prompt:
sql -Usa -i ~sybase/scripts/installpubs2 \ -Slinux_dev

Type your new password when prompted. The script will create a database called pubs2, then create tables with data in them. You can now type queries like the following:
isql -Usa -Slinux_dev Password: 1> use pubs2 2> go 1> select * from authors 2> go au_id au_lname ... ----------- ------------------- ... 172-32-1176 White ... 213-46-8915 Green ... ...

1> quit

Shutting Down the Servers Before you shut down your Linux system, you should shut down your Sybase servers. Do this using the isql program. Log in as the sa user to shut down the server. Once you are in isql, type shutdown SYB_BACKUP to shut down the backup server. SYB_BACKUP is the default name for a backup server. Then type shutdown to shut down the SQL server; this will remove both servers from memory. Now you can shut down your Linux system. If you don't shut down the servers properly, you could corrupt data. I recommend writing a script to perform this task automatically. Starting the Servers To start up the servers, you need to be logged in as the user sybase. Change to the install directory and type:
./startserver -f ./RUN_linux_dev

to start the SQL server and then

./startserver -f ./RUN_linux_dev_bs

to start the backup server. A startup script named /etc/rc.d/init.d/sybase is installed on your system. You can link this script to the proper places in your rc.d directories so the server will automatically start and stop when you start and stop your Linux system. Conclusion You have installed the SQL server and the backup server and you know how to start and stop it. There is still more to learn about the server. At the end of this article is a list of resources that can help you learn about your new Sybase SQL server. I recommend reading the PostScript documentation that comes with the server. If you don't want to print the hundreds of pages of documentation, you can use ghostscript to view them. For an easier way to view the documentation, go to http://sybooks.sybase.com/dynaweb and select Sybase Version 11.0.x Products. You can read all the documentation via Sybase's web site. Next month's installment will be about writing database clients and installing the Sybase extension for Perl (sybperl) that will enable writing database clients in Perl.

Introduction to Sybase, Part 2

From Issue #63 July 1999 Jul 01, 1999 By Jay Sissom in

Software

This month Mr. Sissom shows us how to set up and use a Sybase client written in Perl through examples. Last month, we installed a Sybase database server. This month, we will install a client to access our server. First, we need to understand how the Sybase network interface works. A Sybase client must create a network connection to a database server when it needs to access resources in the database (see Figure 1). Sybase has created a protocol to communicate over the network. This protocol is called the Tabular Data Stream (TDS) protocol. It operates on top of other networking protocols such as TCP/IP on UNIX systems or IPX/SPX on Novell networks. TDS is a proprietary protocol and not documented by Sybase. Fortunately, Sybase has created client libraries which can be used to communicate with the server. A group of people have tried to reverseengineer the TDS protocol. Look at http://sunsite.unc.edu/freetds/ for more information.

Figure 1. TDS Protocol Sybase supports two interfaces to the database. DB-Library is an API that has been used for quite awhile in Sybase products. I believe it is supported for backwards compatibility, and may not be supported in a future version of the product. CTLibrary is the API Sybase created for version 10 and higher products. It supports advanced features such as cursors and asynchronous query processing. You don't need to understand these features to do basic processing with your database server. We will use CT-Library to communicate with our server. We could write our client using C or C++. The libraries required to do this are included with the server. Look for examples in the sample directory under the server directory. There is a subdirectory for DB-Library and one for CT-Library. We don't have to use C or C++, however. An extension to the Perl language called sybperl enables the use of Perl to write clients to access the database. Most Linux distributions come with the Perl language. On my system, I have installed Red Hat 5.1 which includes Perl version 5 by default. Fortunately, it is possible to install sybperl without recompiling Perl. Using this method precludes the use of the DB-Library, which is why we have chosen to use CT-Library. If Perl is not installed on your system, install it now. If your distribution does not provide perl, you can download the source from CPAN (http://www.cpan.org/). Install sybperl First, we must download sybperl from http://www.perl.com/CPANlocal/authors/Michael_Peppler/ The newest version available at the time of this writing is version 2.09_05 in the file sybperl-2.09_05.tar.gz (148KB). Change directories to the location of the sybperl tar file, and issue the command:
perl Makefile.PL

Change to the sybperl directory just created, and edit the CONFIG file. In the line DBLIBVS=1000, change the 1000 to 0. Make sure the line SYBASE=/opt/sybase contains the correct directory for the Sybase server. The line EXTRA_LIBS=-ltli must be changed to EXTRA_LIBS=-linsck. We will build sybperl to work with CT-library. Most Linux distributions come with the Berkeley DB library. If Perl is configured to use this library, a conflict arises when using DB-library at the same time, since both use the call open_database. If you recompile Perl to leave out the Berkeley DB library, you can leave the line DBLIBVS=1000 in the CONFIG file and use DB-library. Save the changes to the CONFIG file, then issue this command:
perl Makefile.PL

This will create a file that will build the software. It looks for the Perl installation in your path. If Perl isn't in your path, you'll need to change your path to include it. Now issue the make command to build the software; it will take a few minutes to run. sybperl has tests that can be run to ensure it is built properly. To run these tests, edit the PWD file to put your sa password and the name of your Sybase server on the proper lines. If you installed the server following the directions in the last issue, the name of the server is linux_dev. Save the file, then type the command
make test

This command will run a series of tests. If everything is working properly, the message All tests successful will be printed. Now, let's install sybperl. If your Perl installation is in a directory that requires root access to modify, change to root using su. Run the command
make install

Perl and sybperl are now installed, so it is time to write some programs. Writing a sybperl Program All of the programs here are available for download. If you type in these programs, be sure to use chmod to make them executable. Listing 1. Writing a sybperl program is quite simple. Listing 1 is our first example program. This will list the names of all the databases in the server. Here is a line-by-line explanation of the program. Line 1 tells Linux which program to use to run this script. This must be the new version of Perl you just installed. Make sure you change this line to point to the correct version of Perl on your system. Line 3 tells Perl to use the CT-library interface to Sybase. It should be at the beginning of all Perl scripts you write that access a Sybase server. Line 5 attaches to the correct Sybase server. The first parameter is the user name, the second is the password and the third is the name of the server. Line 7 is the SQL to run. Lines 9-10 are commands that run the query on the server and return a reference to an array of rows, @rows. Note this command loads the entire result set into memory. This is fine for small result sets, but if you are expecting a large result set, you shouldn't use ct_sql. Later, I will give you an alternative method for executing commands and receiving large result sets. Lines 12-14 will print all rows that were returned.

Listing 2 Listing 2 is an example of a sybperl program that updates data. In Line 7, we use the same ct_sql command to send the SQL to the database, except this time a set of rows is not returned. The insert, delete and update SQL commands also do not return rows. The SQL command use pubs2 tells Sybase to make the pubs2 database the default database for the rest of this session. In Line 10, we again use the ct_sql command to run the SQL. This time, we add a row to the discounts table. You can use the isql program to run an SQL SELECT command to verify that the row was added. Writing a Perl CGI Client Program Linux is mostly used as a web server, and Perl is primarily used to write web applications. So, we will create a Perl program to access the Sybase database. Listing 3 Writing a CGI program to access Sybase is quite simple. Listing 3 is the complete code of a CGI program to let you know who's logged in to your Sybase server. Place this program in your web server's cgi-bin directory. On a default Red Hat system, the directory is /home/httpd/cgi-bin/. For this example, name the program listing3.pl. In lines 5 and 6, we set two environment variables. The Sybase DB-Library and CTLibrary must find these environment variables, or an error will occur. When you run a CGI program, very few environment variables are passed to your program. These two environment variables must be set in each CGI program that needs to access Sybase. If you have many CGI programs, place these commands in a file included in all your CGI programs. The SYBASE environment variable contains the directory of the Sybase software. The DSQUERY variable contains the name of the default server. The only other difference between this example and the others is it outputs HTML to a browser. Other Considerations These example programs show the basics of accessing a Sybase database server. In production programs, a few more things must be taken care of in your programs. Errors from the server must be handled properly. If you ignore them, your program will stop when it encounters a server error. In all our example programs, ct_sql was used to run queries. It works fine for SQL commands and stored procedures which don't return result sets, but would have severe problems for queries returning large result sets. Listing 4

Listing 4 shows how to handle errors and demonstrate a replacement for the ct_sql command. In lines 3 and 4, we establish both a client and a server message call-back routine. These routines will be called when the server or client generates an informational or error message. In lines 7-20, we handle a single SQL statement. Sybase allows a single statement to return multiple result sets. Lines 8-10 will process each result set. Lines 17-19 will handle each row in a result set. Lines 11-16 will look at the result set and print the names and types of each column. A Sybase result set contains more than just datait also includes column definition information. Lines 23-50 are the two call-back routines. These routines are called each time there is a message from the server or client. An example of a client message is the one returned if you can't log in to the server. An example of a server message is the one returned if you have an error in your SQL. All this information can be found within the sybperl and the Sybase documentation. Conclusion The Sybase database server is a powerful piece of software. Unfortunately, all that power comes with a price. Setting up and supporting a Sybase server isn't as easy as using Postgres or MySQL, but if you need a heavy-duty, high-performance database, Sybase is your best bet. Next month, we'll discuss application development using Sybase on Linux. This article will appear in the Strictly On-line section. Jay Sissom is responsible for the web-based front end to the financial decision support data at Indiana University. He has installed and supported Sybase databases on many operating systems and has written database clients for the Web using C, C++ and sybperl and for Windows using tools like Visual Basic and PowerBuilder. When he isn't programming, he enjoys amateur radio and playing his bass guitar and keyboards. If you have questions, you can contact him via e-mail at jsissom@indiana.edu.

Introduction To Sybase, Part 3

From Issue #64 August 1999 Jul 31, 1999 By Jay Sissom in

Software

Writing a Sybase web application. Welcome Back! In the first two parts of this series, we installed the Sybase database and configured the Perl language to work with the database. In part three, we will create a web application using our newly installed database server. Before you can manage an application using the Sybase server, some background information is in order. I will assume you have read the two previous articles in the series. The example program is a bookstore on the Web. We will discuss all aspects of creating and maintaining a client-server application using the Sybase SQL server. You won't be an expert after reading the article, but you'll have a good idea of what needs to be done for client-server applications. The example application will not be able to compete with Amazon.com, but it will give you an idea of how to design a clientserver application. We'll first take a look at some Sybase SQL server basics. Transactions The Sybase SQL Server is a transactional database server. A transaction is a single piece of work. For example, placing an order would be considered one transaction. Moving money from one account to another is one transaction. Even if a transaction affects two tables in our database, the entire transaction should be completed or should not happen at allit should never be half-completed. For example, if you want to transfer $100 from your savings account to your checking account, you either want the transfer to happen or not happen. You don't want the $100 to be removed from your savings account but not placed in your checking account. The SQL to accomplish this transfer would look something like this:
update accounts_t set balance = balance - 100 where account_nbr = 'mysaving'

update accounts_t set balance = balance + 100 where account_nbr = 'mychecking'

The bank wouldn't want the first update to execute without the second one. If it were my account, I know I wouldn't. The Sybase SQL Server allows the developer to denote where a transaction begins and where it ends.
begin transaction update accounts_t set balance = balance - 100 where account_nbr = 'mysaving' if @@error != 0 begin rollback transaction return end update accounts_t set balance = balance + 100 where account_nbr = 'mychecking' if @@error != 0 begin rollback transaction return end commit transaction if @@error != 0 begin rollback transaction end

If you do not use the begin transaction and commit transaction commands, the database server will assume each SQL command is a single transaction. Make sure you use transaction control in your application where it is needed. For more information on transactions, see Chapter 17 in the Transact-SQL User's Guide. Logs The SQL Server uses a log to keep track of all transactions. Each database has its own log. The log is part of the database and is not human readable. Each change made to a database is saved in the database's transaction log. Some databases save their data and log information in the same area. Most databases have separate areas for the data and their log. Each area of a database is called a segment. By default, a database has three segments:

System: stores the database's system tables. Log: stores the database's transaction log. Default: stores all other database objects.

You can create a database where all three segments are on the same device. If you do this, you won't have as much control over the database as you'd like. The best way to create a database is to separate the log segment from the system and default segments. When you create the database, you specify which devices to put the database on. For more information on these segments and on creating your own custom segments, look in chapter 16 of the System Administration Guide (see Resources). For more information on creating databases, look in chapter 14. In our example program, a database called book_d is created with 20MB allocated for data and 10MB for log.

All transactions that modify a database are saved in the database's transaction log. The data in this log will keep increasing until you back up the log to tape or disk. The data in the log will remain even after all transactions are committed. It stays until the log segment is backed up. This means you need to back up your database often, or this log segment will fill up. When the log segment fills up, you cannot make changes to data in this database until you back up the log segment. A function is available that will allow the database server to automatically call a stored procedure when a segment is filling up. So, you can write a stored procedure to automatically back up the log when the segment is close to full. A stored procedure is an object in the database containing SQL code. An example stored procedure called sp_thresholdaction that will back up the log to disk is included in the application. For more information about Threshold procedures, see chapter 21 of the System Administration Guide. Backups Just as any other part of a computer system, databases need to be backed up. One approach would be to shut down the database server, then back up the database device files. This could work, but Sybase says a back up made this way is not guaranteed to restore properly. Each database has to keep track of its logs and the sequence of transactions. If any of these are out of sync with the others, Sybase cannot use the database. Fortunately, Sybase has created a backup server to help you back up your databases. It will even let you run your backups while the database is still up. Your bookstore can stay up 24 hours a day, 7 days a week. You can back up your databases and logs to either disk or tape using the Sybase backup server. To back up to tape, you'll need to configure your tape device. Read Chapter 18 of the System Administration Guide to learn how to configure your tape drive. Depending on the size of your databases, I would recommend backing up the logs at least once during the day and the databases every night. If your databases are huge, you might not be able to do this. Back up the logs as often as you can, but think of log backups as changes made to the database. If the database gets corrupted, you'll need to restore the database, then all the logs you backed up since the database backup was made. If you choose to save logs to a disk drive, I would highly recommend they be saved on a separate disk from the one holding your database. On one of our production database servers, we back up the logs to disk at noon each day, then FTP them to another system. This system has 20 1GB drives on it, so databases and logs are located on different drives, and the log backups are on yet another disk. For best performance, it would be best to keep everything on separate small drives. The system can read and write to multiple drives faster than to a large single drive. Database Consistency

Each time you boot your Linux system, the fsck program is run against all your file systems. The fsck program makes sure all the directories and data are consistent. It is possible for a file system to become out of sync, causing a loss of data. The Sybase database server has a similar command. It is called dbcc (database consistency check). This command makes sure all data allocations are proper and accounted for. These checks should be run regularly on your databases. They can be scheduled just as you schedule your backups. The Bookstore Application You can download the entire application from the Linux Journal FTP server at ftp://ftp.linuxjournal.com/pub/lj/listings/issue64/. To save space, the entire application isn't presented here. There are two tar files: 3250src.tgz and 3250cgi.tgz. The first one has the source code for all database objects. Log in as the sybase user and unpack the tar files. Read the README file before installing. You'll need to install the pubs2 example database shipped with the server. The second tar file has all CGI scripts and other files needed for the application. These files should be placed in the /cgi-bin directory of your web server. Again, read the README file before installing. Sybase and Sybperl must be installed to use this application. Information on this installation is in the first two parts of this article. This isn't an article about web development, so I won't go into great detail about the web aspects of the application. It also isn't a web application beauty contest. You will see I didn't spend much time making it look nice. I'm sure you can find the time to make the application look the way you like it. If you installed the application in the default location, you can start a web browser on your system and go to http://localhost/cgi-bin/store/store/ to run the application. If you receive a File Not Found error message, your CGI application cannot be found. On a default Red Hat 5.x system, the CGI perl script should be located at /home/httpd/cgi-bin/store/store. If you received an Internal Server Error message, your Perl program probably isn't located at /usr/bin/perl. Edit the file /home/httpd/cgi-bin/store/store/ and modify the path for Perl to point to your Perl executable. One way to figure out the problem is to run the Perl script at the command line. You should receive HTML. If you receive an error message, you'll need to resolve this problem. If you receive the store menu, click on Search for Books. If you receive an error message, your client cannot connect to the database. Look at the file /home/httpd/cgibin/store/store.inc/. You may need to change the name of the database server. Make sure your database server is up and running. You should be able to connect to it using the user name and password in the store.inc file. Use the isql program at the command line to test this. Each screen of the application has a subroutine written in Perl. The subroutine is named after the last part of the URL. To search for books, the URL would be http://localhost/cgi-bin/store/store/search/. The subroutine responsible for this is called search.

The Application Database In our application, we use two databases. The first is the pubs2 example database. We use the titles table as the list of books. This table is read-only. We just view it; the application does not make changes to it. The second database is called book_d and it is created on two devices. The log segment is on device02 and has 10MB allocated to it. The data segment is on device01 and has 20MB allocated to it. There are five tables in this database.

inventory_t: this table is a one-to-one relationship to the titles table in the pubs2 database. There is one row in this table for each row in the titles table. This table contains the number of books in stock and the number on order. orders_t: this table is a list of customer orders. order_nbr_t: this table has one row in it. It is used to guarantee that the order number is always unique. types_t: this table is a list of the types of books. It is used to populate the dropdown box on the search screen. user_t: this table is a list of customers.

To provide access to the data, we use stored procedures in all cases except one. Stored procedures are SQL code stored in the database. This allows us to encapsulate procedures in the database so it doesn't have to be replicated in all your applications. It also provides a performance benefit. When the stored procedure is loaded, the SQL is precompiled. When the application runs, the server doesn't have to precompile the SQL, so the application should run faster. We used SQL in the search1 procedure, because it would change dramatically depending on the parameters given. In the scripts, we have also created a user to access the database. Each time the CGI script runs, it logs in as this user. The end users of your application do not need to know this, and in fact, shouldn't know it. Even though this user has the minimum rights necessary to run the application, you should protect this user name and password. This is a very small application. A few more things must be done if you put this application into production.

Make it look nicer. This application would have looked fine in the early 90's, but in today's world, it would need to look much better before people would use it. Prepare and schedule automatic backups. Use cron to back up your data at regular intervals. Prepare and schedule database consistency checks. These should be run regularly, again using cron to schedule these checks. Create and tune table indexes. These tables have no defined indexes. An index is extra data about the table that will allow the database server to access the data faster.

Explaining how the database server uses indexes is beyond the scope of this articleI have a complete book on the subject. Before you put an application into production, you should load example data in all the tables and test queries to be run in your

application. Based on the queries, you can make good guesses as to which indexes will be needed. There is a command in SQL that can help tune indexes. It is set showplan on. Entire book chapters are devoted to explaining this command and its output. Summary As you can see, using a Sybase database as the basis for your client-server applications is not a trivial task. The Sybase database server is an industrial-strength database, capable of handling hundreds of users and many gigabytes of data. Many databases are available for Linux. Of the free ones, I believe the Sybase database server is the most powerful. If you don't need a powerful database, there may be better choices. If, however, you need a high-power database to manage a large amount of data or many users, a Sybase database server would be a solid foundation. Resources Jay Sissom (jsissom@indiana.edu) is responsible for the web-based front end to the financial decision support data at Indiana University. He has installed and supported Sybase databases on many operating systems and has written database clients for the web. When not programming, he enjoys amateur radio and playing his bass guitar and keyboards.