Index: phpdoc/en/faq/databases.xml
diff -u phpdoc/en/faq/databases.xml:1.8 phpdoc/en/faq/databases.xml:1.9
--- phpdoc/en/faq/databases.xml:1.8 Sun Sep 30 14:36:39 2001
+++ phpdoc/en/faq/databases.xml Sun Oct 14 06:26:19 2001
@@ -1,13 +1,14 @@
-
+
Connecting to databasesConnecting to databases
-
- This section holds common questions about relation between PHP and
- databases : Yes, PHP can acces virtually any database available today.
-
+
+ This section holds common questions about relation between
+ PHP and databases. Yes, PHP can access virtually any
+ database available today.
+
@@ -18,17 +19,17 @@
- On Windows 95/NT machines, you can simply use the included ODBC support
+ On Windows machines, you can simply use the included ODBC support
and the correct ODBC driver.
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
- free version of the necessary libraries for Linux systems.
- For other Unix operating systems,
- you need to contact Sybase for the correct libraries. Also see
- the answer to the next question - 4.2.
+ free version of the necessary
+ libraries for Linux systems. For other Unix operating
+ systems, you need to contact Sybase for the correct libraries.
+ Also see the answer to the next question.
@@ -39,231 +40,139 @@
- 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.
-
-
- 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.
- OpenLink Software 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.
-
-
- 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:
-
- 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
- website for a free download.
-
-
-
- One option that has proven successful is to use MySQL and its
- MyODBC drivers on Windows and synchronizing the databases. Steve Lawrence
- writes:
-
-
+ Yes. You already have all the tools you need if you are running
+ entirely under Windows 9x/Me, or NT/2000, where you can use
+ ODBC and Microsoft's ODBC drivers for Microsoft Access databases.
+
+
+ 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.
+ OpenLink Software 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.
+
+
+ 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:
+
+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 website for a free download.
+
+
+
+ One option that has proven successful is to use MySQL and its
+ MyODBC drivers on Windows and synchronizing the databases. Steve Lawrence
+ writes:
+
+
-
- Install MySQL on your platform according to instructions with MySQL.
- Latest available from www.mysql.com
- (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.
-
-
-
-
- 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.
-
-
-
-
- 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.
-
-
-
-
- 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.
-
-
-
-
-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.
-
-
+
+ Install MySQL on your platform according to instructions with MySQL.
+ Latest available from www.mysql.com
+ (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.
+
+
+
+
+ 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.
+
+
+
+
+ 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.
+
+
+
+
+ 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.
+
+
+
+
+ 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.
+
+
Tips and Tricks:
-
-You can construct your tables in access and export them to MySQL, then
-link them back in. That makes table creation quick.
-
-
-
-
-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
-
-
-
-
-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.
-
-
+
+ You can construct your tables in access and export them
+ to MySQL, then link them back in. That makes table
+ creation quick.
+
+
+
+
+ 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
+
+
+
+
+ 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.
+
+
-
+
- I saw PHP offers persistent database connections. What does that mean?
-
-
- 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).
-
-
- 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 not give you an ability
- to open 'user sessions' on the same SQL link, they do not
- 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 any
- functionality that wasn't possible with their non-persistent brothers.
-
-
- Why?
-
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- If persistent connections don't have any added functionality,
- what are they good for?
-
-
- 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.
-
-
- An important summary. Persistent connections were designed to
- have one-to-one mapping to regular connections. That means that you
- should always be able to replace persistent connections with
- non-persistent connections, and it won't change the way your script
- behaves. It may (and probably will) change the efficiency
- of the script, but not its behavior!
+ I upgraded to PHP 4, and now mysql keeps telling me
+ "Warning: MySQL: Unable to save result set in ...". What's up?
-
-
-
-
-
- I upgraded to php4, and now mysql keeps telling me "Warning: MySQL: Unable to save result set in ...". What's up?
- 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
+ Most likely what has happened is, PHP 4 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 PHP 3 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.
- Recompiling php4, and adding the path to mysql to the flag,
+ Recompiling PHP 4, and adding the path to MySQL to the flag,
'--with-mysql=/your/path/to/mysql'
usually solves the problem.
@@ -273,17 +182,17 @@
- After installing shared mysql support, Apache dumps core as soon
+ After installing shared MySQL support, Apache dumps core as soon
as libphp4.so is loaded. Can this be fixed?
- 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,
+ 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.
+ fix this. Then recompile PHP with the new MySQL libs.
Index: phpdoc/en/features/persistent-connections.xml
diff -u phpdoc/en/features/persistent-connections.xml:1.12 phpdoc/en/features/persistent-connections.xml:1.13
--- phpdoc/en/features/persistent-connections.xml:1.12 Fri Sep 21 18:47:32 2001
+++ phpdoc/en/features/persistent-connections.xml Sun Oct 14 06:26:19 2001
@@ -1,5 +1,5 @@
-
+
Persistent Database Connections
@@ -60,7 +60,7 @@
The last method is to use PHP as a plug-in for a multithreaded web
server. Currently PHP 4 has support for ISAPI, WSAPI, and NSAPI (on
Windows), which all allow PHP to be used as a plug-in on multithreaded
- servers like Netscape FastTrack, Microsoft's Internet Information
+ servers like Netscape FastTrack (iPlanet), Microsoft's Internet Information
Server (IIS), and O'Reilly's WebSite Pro. The behavior is essentially
the same as for the multiprocess model described before. Note that
SAPI support is not available in PHP 3.