dams Fri Jul 20 14:10:51 2001 EDT
Added files:
/phpdoc/en/faq databases.xml
Log:
Initial Adding to faq
Index: phpdoc/en/faq/databases.xml
+++ phpdoc/en/faq/databases.xml
<chapter id="faq.databases">
<title>PHP mailing lists</title>
<titleabbrev>PHP mailing lists</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 www.mysql.org (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>add-ins>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:
-->
