php-doc-en/faq/databases.xml

<?xml encoding="iso-8859-1"?>
<!-- $Revision: 1.6 $ -->
 <chapter id="faq.databases">
  <title>Connecting to databases</title>
  <titleabbrev>Connecting to databases</titleabbrev>

   <para>
    This section holds common questions about relation between PHP and
    databases : Yes, PHP can acces virtually any database available today.
   </para>

  <qandaset>
   <qandaentry id="faq.databases.mssql">
    <question>
     <para>
      I heard it's possible to access Microsoft SQL Server from PHP. How?
     </para>
    </question>
    <answer>
     <para>
      On Windows 95/NT machines, you can simply use the included ODBC support
      and the correct ODBC driver.
     </para>
     <para>
      On Unix machines, you can use the Sybase-CT driver
      to access Microsoft SQL Servers because they are (at
      least mostly) protocol-compatible. Sybase has made a 
      <ulink url="&faqurl.sybase;">free version of the necessary libraries for Linux systems</ulink>.
      For other Unix operating systems,
      you need to contact Sybase for the correct libraries.  Also see
      the answer to the next question - 4.2.
     </para>
    </answer>
   </qandaentry>

   <qandaentry id="faq.databases.access">
    <question>
     <para>Can I access Microsoft Access databases?</para>
    </question>
    <answer>
     <para>
    Yes. You already have all the tools you need if you are running
    entirely under Windows 95/98 or NT, where you can use ODBC and Microsoft's
    ODBC drivers for Microsoft Access databases.
    </para>
    <para>
    If you are running PHP on a Unix box and want to talk to MS-Access on
    a Windows box you will need Unix ODBC drivers.
    <ulink url="&faqurl.openlinksw;">OpenLink Software</ulink> has Unix-based
    ODBC drivers that can do this.  There is a free pilot program where you
    can download an evaluation copy that doesn't expire and prices start at
    $675 for the commercial supported version.
    </para>
    <para>
    Another alternative is to use an SQL server that has
    Windows ODBC drivers and use that to store the data, which you can
    then access from Microsoft Access (using ODBC) and PHP (using the
    built-in drivers), or to use an intermediary file format that Access
    and PHP both understand, such as flat-files or dBase databases.
    On this point Tim Hayes from OpenLink software writes:
     <programlisting>
      Using another database as an intermediary is not a good idea, when you can
      use ODBC from PHP straight to your database - i.e. with OpenLink's drivers. If
      you do need to use an intermediary file format, OpenLink have now released
      Virtuoso (a virtual database engine) for NT, Linux and other unix platforms.
      Please visit our
      <ulink url="&faqurl.openlinksw;">website</ulink> for a free download.
     </programlisting>
    </para>
    <para>
     One option that has proven successful is to use MySQL and its
    MyODBC drivers on Windows and synchronizing the databases.  Steve Lawrence
    writes:
    </para>
    <para>
      <itemizedlist>
       <listitem>
 	    <simpara>
 	     Install MySQL on your platform according to instructions with MySQL.
 	     Latest available from <ulink url="&faqurl.mysql;">www.mysql.com</ulink>
 	     (get it from your mirror!). No special
 	     configuration required except when you set up a database, and configure the
 	     user account, you should put % in the host field, or the host name of the
 	     Windows computer you wish to access MySQL with. Make a note of your server
 	     name, username, and password.
 	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
 	     Download the MyODBC for Windows driver from the MySQL site. Latest
 	     release is myodbc-2_50_19-win95.zip (NT available too, as well as source
 	     code). Install it on your Windows machine. You can test the operation with
 	     the utilities included with this program.
 	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
 	     Create a user or system dsn in your ODBC administrator, located in the
 	     control panel. Make up a dsn name, enter your hostname, user name, password,
 	     port, etc for you MySQL database configured in step 1.
 	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
 	     Install Access with a full install, this makes sure you get the proper
 	     add-ins.. at the least you will need ODBC support and the linked table
 	     manager.
 	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
Now the fun part! Create a new access database. In the table window right
click and select Link Tables, or under the file menu option, select Get
External Data and then Link Tables. When the file browser box comes up,
select files of type: ODBC. Select System dsn and the name of your dsn
created in step 3. Select the table to link, press ok, and presto! you can
now open the table and add/delete/edit data on your MySQL server! You can
also build queries, import/export tables to MySQL, build forms and reports,
etc. 
	    </simpara>
 	   </listitem>
      </itemizedlist>
     </para>
     <para>
      Tips and Tricks:
      <itemizedlist>
       <listitem>
 	    <simpara>
You can construct your tables in access and export them to MySQL, then
link them back in. That makes table creation quick.
	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
When creating tables in access, you must have a primary key defined in
order to have write access to the table in access. Make sure you create a
primary key in MySQL before linking in access
	    </simpara>
 	   </listitem>
       <listitem>
 	    <simpara>
If you change a table in MySQL, you have to re-link it in access. Go to
tools&gt;add-ins&gt;linked table manager, cruise to your ODBC DSN, and select the
table to re-link from there. you can also move your dsn source around there,
just hit the always prompt for new location checkbox before pressing ok.
	    </simpara>
 	   </listitem>
      </itemizedlist>
     </para>
    </answer>
   </qandaentry>

   <qandaentry id="faq.databases.persistent">
    <question>
     <para>I saw PHP offers persistent database connections. What does that mean?</para>
    </question>
    <answer>
     <para>
    Persistent connections are SQL links that do not close when the
    execution of your script ends.  When a persistent connection is
    requested, PHP checks if there's already an identical persistent
    connection (that remained open from earlier) - and if it exists, it
    uses it.  If it does not exist, it creates the link.  An 'identical'
    connection is a connection that was opened to the same host, with
    the same username and the same password (where applicable).
     </para>
     <para>
    People who aren't thoroughly familiar with the way web servers
    work and distribute the load may mistake persistent connects for what
    they're not.  In particular, they do <emphasis>not</emphasis> give you an ability
    to open 'user sessions' on the same SQL link, they do <emphasis>not</emphasis>
    give you an ability to build up a transaction efficently, and they
    don't do a whole lot of other things.  In fact, to be extremely
    clear about the subject, persistent connections don't give you <emphasis>any</emphasis>
    functionality that wasn't possible with their non-persistent brothers.
     </para>
     <para>
    Why?
     </para>
     <para>
    This has to do with the way web servers work. There are three ways
    in which your web server can utilize PHP to generate web pages.
     </para>
     <para>
    The first method is to use PHP as a CGI "wrapper". When run this
    way, an instance of the PHP interpreter is created and destroyed for
    every page request (for a PHP page) to your web server. Because it
    is destroyed after every request, any resources that it acquires (such
    as a link to an SQL database server) are closed when it is destroyed.
    In this case, you do not gain anything from trying to use persistent
    connections -- they simply don't persist.
     </para>
     <para>
    The second, and most popular, method is to run PHP as a module
    in a multiprocess web server, which currently only includes
    Apache. A multiprocess server typically has one process (the parent)
    which coordinates a set of processes (its children) who actually do
    the work of serving up web pages. When each request comes in from a a
    client, it is handed off to one of the children that is not already
    serving another client. This means that when the same client makes
    a second request to the server, it may be serviced by a different
    child process than the first time. What a persistent connection does
    for you in this case it make it so each child process only needs
    to connect to your SQL server the first time that it serves a page
    that makes us of such a connection. When another page then requires
    a connection to the SQL server, it can reuse the connection that
    child established earlier.
     </para>
     <para>
    The last method is to use PHP as a plug-in for a multithreaded
    web server. Currently this is only theoretical -- PHP does not
    yet work as a plug-in for any multithreaded web servers. Work is
    progressing on support for ISAPI, WSAPI, and NSAPI (on Windows),
    which will all allow PHP to be used as a plug-in on multithreaded
    servers like Netscape FastTrack, Microsoft's Internet Information
    Server (IIS), and O'Reilly's WebSite Pro. When this happens, the
    behavior will be essentially the same as for the multiprocess model
    described before.
     </para>
     <para>
    If persistent connections don't have any added functionality,
    what are they good for?
     </para>
     <para>
    The answer here is extremely simple -- efficiency.  Persistent
    connections are good if the overhead to create a link to your SQL
    server is high.  Whether or not this overhead is really high depends
    on many factors.  Like, what kind of database it is, whether or
    not it sits on the same computer on which your web server sits,
    how loaded the machine the SQL server sits on is and so forth.
    The bottom line is that if that connection overhead is high,
    persistent connections help you considerably.  They cause the child
    process to simply connect only once for its entire lifespan, instead
    of every time it processes a page that requires connecting to the
    SQL server.  This means that for every child that opened a persistent
    connection will have its own open persistent connection to the server.
    For example, if you had 20 different child processes that ran a script
    that made a persistent connection to your SQL server, you'd have 20
    different connections to the SQL server, one from each child.
     </para>
     <para>
    An important summary.  Persistent connections were designed to
    have one-to-one mapping to regular connections.  That means that you
    should <emphasis>always</emphasis> be able to replace persistent connections with
    non-persistent connections, and it won't change the way your script
    behaves.  It <emphasis>may</emphasis> (and probably will) change the efficiency
    of the script, but not its behavior!     
     </para>
    </answer>
   </qandaentry>
  
   <qandaentry id="faq.databases.upgraded">
    <question>
     <para>I upgraded to php4, and now mysql keeps telling me "Warning: MySQL: Unable to save result set in ...". What's up?</para>
    </question>
    <answer>
     <para>
      Most likely what has happened is, PHP4 was compiled with the '--with-mysql'
      option, without specifying the path to mysql. This means PHP is using its
      built-in mysql client library. If your system is running applications,
      such as php3 as a concurrent Apache module, or auth-mysql, that use other
      versions of mysql clients, then there is a conflict between the two
      differing versions of those clients.
     </para>
     <para>
      Recompiling php4, and adding the path to mysql to the flag,
      '<link linkend="install.configure.with-mysql">--with-mysql=/your/path/to/mysql</link>' 
      usually solves the problem.
     </para>
    </answer>
   </qandaentry>
   
   <qandaentry id="faq.databases.shared_mysql">
    <question>
     <para>
      After installing shared mysql support, Apache dumps core as soon
      as libphp4.so is loaded. Can this be fixed?
     </para>
    </question>
    <answer>
     <para>
      If your MySQL libs are linked against pthreads this will happen.  Check
      using ldd.  If they are, grab the MySQL tarball and compile from source,
      or recompile from the source rpm and remove the switch in the spec file
      that turns on the threaded client code. Either of these suggestions will
      fix this. Then recompile PHP with the new mysql libs.
     </para>
    </answer>
   </qandaentry>
  </qandaset>
 </chapter>

 <!-- Keep this comment at the end of the file
 Local variables:
 mode: sgml
 sgml-omittag:t
 sgml-shorttag:t
 sgml-minimize-attributes:nil
 sgml-always-quote-attributes:t
 sgml-indent-step:1
 sgml-indent-data:t
 sgml-parent-document:nil
 sgml-default-dtd-file:"../../manual.ced"
 sgml-exposed-tags:nil
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:
 -->