Nabble - Php - Database

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T13:02:44Z

Sara Leavitt wrote:
> How about combining MySQLi with mysql_pconnect? Assuming both are
> persistent, would those connections be shared?
> The goal here is to use prepared statements. I read that MySQLi only
> supports persistent connections in php version 5.3 which we are not yet
> running, but perhaps it would be worth waiting for 5.3.
>
> -Sara

The mysqli extension appears to use "mysqli_" as the hash key prefix
so there won't be PHP connection structure sharing here either.

Chris

>
>
> Christopher Jones wrote:
>>
>>
>> Andy Shellam (Mailing Lists) wrote:
>> > "First, when connecting, the function would first try to find a
>> > (persistent) link that's already open with the same host, username
>> > and password. If one is found, an identifier for it will be returned
>> > instead of opening a new connection."
>> >
>> > Therefore, providing you've configured PHP's --with-mysql and
>> > --with-pdo-mysql options with the same MySQL library, then as long
>> > as the host, username and password are the same, the same connection
>> > will be re-used for both the native (mysql_pconnect) connection and
>> > the PDO connection.
>>
>> The doc refers to the PHP end of the connection and only to any
>> existing PDO connection. PDO uses a hash table for open connections
>> which it scans for matches when a PDO connection call is executed.
>> The hash key is unique and begins with "PDO:DBH:DSN=". The mysql
>> extension uses "mysql_" for its hash key prefix. This mean the PHP
>> data structures for persistent connections won't be shared between the
>> two extensions.
>>
>> Whether the MySQL client library or the MySQL database reuses any
>> connection data underneath, I don't know. In Oracle the answer would
>> be that PDO_OCI and OCI8 connections are distinct and transactionally
>> separate (though they could share the same database connection pool if
>> one was enabled).
>>
>> Chris
>>

--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T12:11:53Z

How about combining MySQLi with mysql_pconnect? Assuming both are
persistent, would those connections be shared?

The goal here is to use prepared statements. I read that MySQLi only
supports persistent connections in php version 5.3 which we are not yet
running, but perhaps it would be worth waiting for 5.3.

-Sara

Christopher Jones wrote:

>
>
> Andy Shellam (Mailing Lists) wrote:
> > "First, when connecting, the function would first try to find a
> > (persistent) link that's already open with the same host, username
> > and password. If one is found, an identifier for it will be returned
> > instead of opening a new connection."
> >
> > Therefore, providing you've configured PHP's --with-mysql and
> > --with-pdo-mysql options with the same MySQL library, then as long
> > as the host, username and password are the same, the same connection
> > will be re-used for both the native (mysql_pconnect) connection and
> > the PDO connection.
>
> The doc refers to the PHP end of the connection and only to any
> existing PDO connection. PDO uses a hash table for open connections
> which it scans for matches when a PDO connection call is executed.
> The hash key is unique and begins with "PDO:DBH:DSN=". The mysql
> extension uses "mysql_" for its hash key prefix. This mean the PHP
> data structures for persistent connections won't be shared between the
> two extensions.
>
> Whether the MySQL client library or the MySQL database reuses any
> connection data underneath, I don't know. In Oracle the answer would
> be that PDO_OCI and OCI8 connections are distinct and transactionally
> separate (though they could share the same database connection pool if
> one was enabled).
>
> Chris
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T11:47:53Z

Andy Shellam (Mailing Lists) wrote:
> "First, when connecting, the function would first try to find a
> (persistent) link that's already open with the same host, username
> and password. If one is found, an identifier for it will be returned
> instead of opening a new connection."
>
> Therefore, providing you've configured PHP's --with-mysql and
> --with-pdo-mysql options with the same MySQL library, then as long
> as the host, username and password are the same, the same connection
> will be re-used for both the native (mysql_pconnect) connection and
> the PDO connection.

The doc refers to the PHP end of the connection and only to any
existing PDO connection. PDO uses a hash table for open connections
which it scans for matches when a PDO connection call is executed.
The hash key is unique and begins with "PDO:DBH:DSN=". The mysql
extension uses "mysql_" for its hash key prefix. This mean the PHP
data structures for persistent connections won't be shared between the
two extensions.

Whether the MySQL client library or the MySQL database reuses any
connection data underneath, I don't know. In Oracle the answer would
be that PDO_OCI and OCI8 connections are distinct and transactionally
separate (though they could share the same database connection pool if
one was enabled).

Chris

--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T11:22:32Z

>
> One thing to be careful is if you are relying on 'transactions' to handle anything. Obviously the transaction has to be in the same connection just to work. Despite what others have said, the PDO connection will be different to the generic mysql connection as it is a separate process. Persistent connections will only reuse an already open connection, you can't connect two processes to the same connection. You would not know which process was accessing things.

According to the documentation:

"First, when connecting, the function would first try to find a (persistent) link that's already open with the same host, username and password. If one is found, an identifier for it will be returned instead of opening a new connection."

Therefore, providing you've configured PHP's --with-mysql and --with-pdo-mysql options with the same MySQL library, then as long as the host, username and password are the same, the same connection will be re-used for both the native (mysql_pconnect) connection and the PDO connection.

I'm not sure about the mysqli library, but I believe that lies beneath the mysql_* family of functions anyway so it shouldn't make a difference whether you're using libmysqlclient or mysqli.

Regards,
Andy

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T10:43:22Z

Sara Leavitt wrote:
> So I can see that using two connections for updating might get out of
> synch; however, mixing the connections should be OK for a series of
> SELECT queries on the read-only side of the application, right?

Yes - if you are only reading already stored data there should not be a problem.

> -Sara
>
> Lester Caine wrote:
>> Sara Leavitt wrote:
>>> Hi Lester,
>>>
>>> Our application is not using php transactions (e.g., COMMIT, ROLLBACK
>>> etc.), so I think we are safe there. Are you saying that even if
>>> both the mysql_pconnect and PDO connection are persistent that they
>>> will be completely separate? (Havn't had a chance to test this
>>> empirically just yet.)
>>
>> Yes ... I'm not totally sure about how MySQL works by default, but
>> having 'committed' data on one connection, one would need to refresh
>> the other connection possibly to see that data. Firebird is a lot more
>> manageable on transaction control, and basically data entered on on
>> connection will not be visible on the other until properly committed.
>> Having that activity hidden in the drivers can lead to a little
>> 'confusion' as to what state data is actually in ....
>>
>> Even just opening two connections via the MySQL driver will have the
>> same effect.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T10:00:02Z

So I can see that using two connections for updating might get out of
synch; however, mixing the connections should be OK for a series of
SELECT queries on the read-only side of the application, right?

-Sara

Lester Caine wrote:

> Sara Leavitt wrote:
>> Hi Lester,
>>
>> Our application is not using php transactions (e.g., COMMIT, ROLLBACK
>> etc.), so I think we are safe there. Are you saying that even if
>> both the mysql_pconnect and PDO connection are persistent that they
>> will be completely separate? (Havn't had a chance to test this
>> empirically just yet.)
>
> Yes ... I'm not totally sure about how MySQL works by default, but
> having 'committed' data on one connection, one would need to refresh
> the other connection possibly to see that data. Firebird is a lot more
> manageable on transaction control, and basically data entered on on
> connection will not be visible on the other until properly committed.
> Having that activity hidden in the drivers can lead to a little
> 'confusion' as to what state data is actually in ....
>
> Even just opening two connections via the MySQL driver will have the
> same effect.
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T09:47:22Z

Sara Leavitt wrote:
> Hi Lester,
>
> Our application is not using php transactions (e.g., COMMIT, ROLLBACK
> etc.), so I think we are safe there. Are you saying that even if both
> the mysql_pconnect and PDO connection are persistent that they will be
> completely separate? (Havn't had a chance to test this empirically just
> yet.)

Yes ... I'm not totally sure about how MySQL works by default, but having
'committed' data on one connection, one would need to refresh the other
connection possibly to see that data. Firebird is a lot more manageable on
transaction control, and basically data entered on on connection will not be
visible on the other until properly committed. Having that activity hidden in
the drivers can lead to a little 'confusion' as to what state data is actually
in ....

Even just opening two connections via the MySQL driver will have the same effect.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T09:30:52Z

Hi Lester,

Our application is not using php transactions (e.g., COMMIT, ROLLBACK
etc.), so I think we are safe there. Are you saying that even if both
the mysql_pconnect and PDO connection are persistent that they will be
completely separate? (Havn't had a chance to test this empirically just
yet.)

Thanks, Sara

Lester Caine wrote:

> Sara Leavitt wrote:
>> Hi,
>>
>> We are about to convert all of our queries using mysql_pconnect to
>> prepared statements using PDO database connections. It will take some
>> time to convert the hundreds of SQL statements so the plan is to do it
>> in phases. Is it a bad idea to have both a mysql_pconnect and a PDO
>> connection open for the same application? Will this doubling of our
>> database connections for every page hit degrade performance? Any tips
>> on the best way to transition to PDO/prepared statements with minimal
>> disruption?
>
> One thing to be careful is if you are relying on 'transactions' to
> handle anything. Obviously the transaction has to be in the same
> connection just to work. Despite what others have said, the PDO
> connection will be different to the generic mysql connection as it is
> a separate process. Persistent connections will only reuse an already
> open connection, you can't connect two processes to the same
> connection. You would not know which process was accessing things.
>

--
Sara Leavitt, UC Berkeley Event Calendar Coordinator
Public Affairs, University of California
2200 Bancroft Way
Berkeley, CA 94720-4204
Phone: 510 643-6163
http://events.berkeley.edu

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-10T00:21:14Z

Sara Leavitt wrote:

> Hi,
>
> We are about to convert all of our queries using mysql_pconnect to
> prepared statements using PDO database connections. It will take some
> time to convert the hundreds of SQL statements so the plan is to do it
> in phases. Is it a bad idea to have both a mysql_pconnect and a PDO
> connection open for the same application? Will this doubling of our
> database connections for every page hit degrade performance? Any tips
> on the best way to transition to PDO/prepared statements with minimal
> disruption?

One thing to be careful is if you are relying on 'transactions' to handle
anything. Obviously the transaction has to be in the same connection just to
work. Despite what others have said, the PDO connection will be different to the
generic mysql connection as it is a separate process. Persistent connections
will only reuse an already open connection, you can't connect two processes to
the same connection. You would not know which process was accessing things.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-09T14:36:23Z

>
> As long as you test it (hopefully using some sort of automated tests) you should be right.
>
> Since you're using persistent connections (make sure you set pdo to do the same), I don't think you're really doubling the number of connections.

Yeah, I think PDO uses the underlying mysql/pgsql functions anyway - it just provides a common API layer across all database types.

Therefore if you call mysql_pconnect outside of PDO, then call the same database server with PDO, technically it should realise the connection has already been made to that server and use your previous connection.

As Chris pointed out, make sure PDO will also use persistent connections.

Regards,
Andy

Re: Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-09T14:12:05Z

Sara Leavitt wrote:

As long as you test it (hopefully using some sort of automated tests)
you should be right.

Since you're using persistent connections (make sure you set pdo to do
the same), I don't think you're really doubling the number of connections.

Check your mysql logs to see if you are doing double connections or not
- that way you'll know for sure.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Group by

2009-12-09T14:09:19Z

Philip Thompson wrote:

> On Dec 9, 2009, at 12:58 PM, host@... wrote:
>
>> The only SELECT is on MAX('timestamp'). There is really nothing to Group BY in this query.
>>
>> Dewey
>>
>> Philip Thompson wrote:
>>> Hi.
>>>
>>> In a mysql query, it is recommended that "GROUP BY" fields be indexed? Using EXPLAIN on one of my queries, I noticed no change between having indexed by GROUP BY field and not indexing it. Any thoughts would be appreciated.

You won't with only 10 rows in the table.

>>> In this example, should `history_field` be indexed...?
>>>
>>> SELECT MAX(`timestamp`) AS `max_ts` FROM `history` WHERE `req_id` = 17 AND `history_record_id` = 35
>>> GROUP BY `history_field`

I'd index
req_id, history_record_id, history_field, timestamp

If you're using myisam tables then all the data can be fetched directly
from the index instead of hitting the data table as well. If you're
using innodb, it'll at least use this index to search for req_id and
history_record_id (assuming these fields are normally in your queries).

> There's only 10 records in table right now... but the # of rows it's going to traverse before find the results is very small.

In theory. Sometimes databases don't work that way and instead of
choosing a particular index you'd expect it to, it'll pick another one.
Fill up the table(s) and make sure it does what you expect. Mysql isn't
great at subselects either.

> Do I need to include `history_field` in the inner select?

No, you don't have to.

You could do a query like:

select count(id) from table group by another_field;

so you get a count per another_field of how many records there are. Not
a great example as normally you would include another_field in the
select, but you don't have to.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Group by

2009-12-09T11:49:44Z

On Dec 9, 2009, at 12:58 PM, host@... wrote:

> The only SELECT is on MAX('timestamp'). There is really nothing to Group BY in this query.
>
> Dewey
>
> Philip Thompson wrote:
>> Hi.
>>
>> In a mysql query, it is recommended that "GROUP BY" fields be indexed? Using EXPLAIN on one of my queries, I noticed no change between having indexed by GROUP BY field and not indexing it. Any thoughts would be appreciated.
>>
>> In this example, should `history_field` be indexed...?
>>
>> SELECT MAX(`timestamp`) AS `max_ts` FROM `history` WHERE `req_id` = 17 AND `history_record_id` = 35
>> GROUP BY `history_field`
>>
>> Thanks,
>> ~Philip

Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-09T11:11:50Z

Hi,

We are about to convert all of our queries using mysql_pconnect to
prepared statements using PDO database connections. It will take some
time to convert the hundreds of SQL statements so the plan is to do it
in phases. Is it a bad idea to have both a mysql_pconnect and a PDO
connection open for the same application? Will this doubling of our
database connections for every page hit degrade performance? Any tips
on the best way to transition to PDO/prepared statements with minimal
disruption?

-Sara

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Group by

2009-12-09T10:58:49Z

The only SELECT is on MAX('timestamp'). There is really nothing to
Group BY in this query.

Dewey

Philip Thompson wrote:

> Hi.
>
> In a mysql query, it is recommended that "GROUP BY" fields be indexed? Using EXPLAIN on one of my queries, I noticed no change between having indexed by GROUP BY field and not indexing it. Any thoughts would be appreciated.
>
> In this example, should `history_field` be indexed...?
>
> SELECT MAX(`timestamp`) AS `max_ts`
> FROM `history`
> WHERE `req_id` = 17 AND `history_record_id` = 35
> GROUP BY `history_field`
>
> Thanks,
> ~Philip
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Combing PDO with mysql_pconnect connections in one application -- will this degrade performance?

2009-12-09T10:56:10Z

Hi,

We are about to convert all of our queries using mysql_pconnect to
prepared statements using PDO database connections. It will take some
time to convert the hundreds of SQL statements so the plan is to do it
in phases. Is is bad idea to have both a mysql_pconnect and a PDO
connection open for the same application? Will this doubling of our
database connections for every page hit degrade performance? Any tips
on the best way to transition to PDO/prepared statements with minimal
disruption?

-Sara

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Group by

2009-12-09T09:56:11Z

Also you may not see a difference because your not even using
'History_field' anywhere in your SELECT statement. I am a little surprised
that you didn't receive a error.

On Wed, Dec 9, 2009 at 9:31 AM, Juan Pablo Ramirez <
ramirez.juanpablo@...> wrote:

> Hi i recommend always use indexes when programming. developers tend not
> to.. and when the databases grows it's difficult to modify or make them
> modify the code.
>
>
>
> El mié, 09-12-2009 a las 14:22 -0300, Julio Araya escribió:
> > On Wed, Dec 9, 2009 at 12:52 PM, Philip Thompson <
> philthathril@...> wrote:
> > > Hi.
> > >
> > > In a mysql query, it is recommended that "GROUP BY" fields be indexed?
> Using EXPLAIN on one of my queries, I noticed no change between having
> indexed by GROUP BY field and not indexing it. Any thoughts would be
> appreciated.
> > >
> > > In this example, should `history_field` be indexed...?
> > >
> > > SELECT MAX(`timestamp`) AS `max_ts`
> > > FROM `history`
> > > WHERE `req_id` = 17 AND `history_record_id` = 35
> > > GROUP BY `history_field`
> >
> > always depends on how many records you have, if you have 100-1000
> > records is very diferent to 100000-500000
> >
> >
> > >
> > > Thanks,
> > > ~Philip
> > > --
> > > PHP Database Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> >
> >
> > --
> > Julio Araya C. Linux User
> #386141
> > Memorista de Ingeniería Civil Informática Ubuntu User #14778
> > Universidd Técnica Federico Santa María Valparaíso - Chile
> >
>
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
<a href="http://www.c28.com/?adid=st&iid=19467">
<img src="http://www.c28.com/images/banner_88x31.gif" border="0" width="88"
height="31"></a>

Re: Group by

2009-12-09T09:31:07Z

Hi i recommend always use indexes when programming. developers tend not
to.. and when the databases grows it's difficult to modify or make them
modify the code.

El mié, 09-12-2009 a las 14:22 -0300, Julio Araya escribió:

> On Wed, Dec 9, 2009 at 12:52 PM, Philip Thompson <philthathril@...> wrote:
> > Hi.
> >
> > In a mysql query, it is recommended that "GROUP BY" fields be indexed? Using EXPLAIN on one of my queries, I noticed no change between having indexed by GROUP BY field and not indexing it. Any thoughts would be appreciated.
> >
> > In this example, should `history_field` be indexed...?
> >
> > SELECT MAX(`timestamp`) AS `max_ts`
> > FROM `history`
> > WHERE `req_id` = 17 AND `history_record_id` = 35
> > GROUP BY `history_field`
>
> always depends on how many records you have, if you have 100-1000
> records is very diferent to 100000-500000
>
>
> >
> > Thanks,
> > ~Philip
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> Julio Araya C. Linux User #386141
> Memorista de Ingeniería Civil Informática Ubuntu User #14778
> Universidd Técnica Federico Santa María Valparaíso - Chile
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Group by

2009-12-09T09:22:21Z

On Wed, Dec 9, 2009 at 12:52 PM, Philip Thompson <philthathril@...> wrote:

always depends on how many records you have, if you have 100-1000
records is very diferent to 100000-500000

>
> Thanks,
> ~Philip
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Julio Araya C. Linux User #386141
Memorista de Ingeniería Civil Informática Ubuntu User #14778
Universidd Técnica Federico Santa María Valparaíso - Chile

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Group by

2009-12-09T07:52:31Z

Hi.

In a mysql query, it is recommended that "GROUP BY" fields be indexed? Using EXPLAIN on one of my queries, I noticed no change between having indexed by GROUP BY field and not indexing it. Any thoughts would be appreciated.

In this example, should `history_field` be indexed...?

SELECT MAX(`timestamp`) AS `max_ts`
FROM `history`
WHERE `req_id` = 17 AND `history_record_id` = 35
GROUP BY `history_field`

Thanks,
~Philip
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Multiple MySQL schemas

2009-12-08T10:51:49Z

On Tue, Dec 8, 2009 at 12:54 PM, Philip Thompson <philthathril@...> wrote:

> Hi all.
>
> We are wanting to create an app that contains multiple clients. Each clients has anywhere from 1 user to more than a hundred. We had the idea of separating each client into its own database schema. This reduces the single point of failure - if 1 client db dies, it doesn't kill the others. This keeps the individual schemas smaller, which will allow us to asynchronously (for lack of a better word) transfer our backups to our network w/o causing bottlenecks. It also guarantees the separation of data (even though the application takes care of this, it's *that extra step*).
>
> Is it reasonable to create a new database per client? Or should we cluster several clients together (5-10) into a single database? What are the pros and cons of each? Note that some clients are *linked* and share data, so those would not be mutually exclusive. What is the maximum number of schemas per MySQL instance - I'm guessing this is based on the filesystem (RHEL)?
>
> Thanks in advance,
> ~Philip
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Phil,

We do exactly that, having one db per client. As you say, it handles
the separation of data. This should be the only reason to separate the
dbs, if the data is sensitive enough to require that.

The one thing to think about is to create a different user for each DB
instance to ensure that if someone compromises on DB that they can't
automatically gain access to the others. Also ensure that the user
account has the least required privileges needed to do the job. That
may mean more account maintenance headaches for you, but will keep the
data safer, as there is no need to have the user account have admin
privileges on the db for any reason.
--

Bastien

Cat, the other other white meat

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Multiple MySQL schemas

2009-12-08T09:54:25Z

Hi all.

We are wanting to create an app that contains multiple clients. Each clients has anywhere from 1 user to more than a hundred. We had the idea of separating each client into its own database schema. This reduces the single point of failure - if 1 client db dies, it doesn't kill the others. This keeps the individual schemas smaller, which will allow us to asynchronously (for lack of a better word) transfer our backups to our network w/o causing bottlenecks. It also guarantees the separation of data (even though the application takes care of this, it's *that extra step*).

Is it reasonable to create a new database per client? Or should we cluster several clients together (5-10) into a single database? What are the pros and cons of each? Note that some clients are *linked* and share data, so those would not be mutually exclusive. What is the maximum number of schemas per MySQL instance - I'm guessing this is based on the filesystem (RHEL)?

Thanks in advance,
~Philip
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: unlink problems

2009-11-26T07:15:17Z

2009/11/25 Neil Jackson <neil@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> I use the following to delete a file on a webserver
>
> if( unlink( "./$filename" ) )
> {
> echo $filename." deleted ";
> $action='';
> echo
> "<script>document.location.href='$PHP_SELF?action=$action&code=$code'</script>";
> }
>
> But I get the following error
> Warning: unlink(./6 November 2009.pdf): No such file or directory in
> /srv/www/htdocs/bee_partners/admin/tenders.php on line 82 6 November
> 2009.pdf not deleted
>
> Any help?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iEYEARECAAYFAksNBV4ACgkQGgk1S8edB3JqWgCfb61pxGvh+KCXNfNdWgF2kb/P
> xCMAn2dSOgN9AiFYX35Ga00XyxZQwGnw
> =NL6k
> -----END PGP SIGNATURE-----
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Not exactly sure what help you would need? The file doesn't exist, so
you can't delete it.

But a quick hack later ...

http://www.beepartners.com/tenders/

is where the files are and

http://www.beepartners.com/admin/tenders.php

is where the script it.

So, "./$filename" should probably be "../tenders/$filename" maybe.

Regards,

Richard.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: unlink problems

2009-11-25T20:58:54Z

Gunawan Wibisono wrote:
> kesavan is right !!
> i see the problem in link..
>
> u type "./blabla.pdf" the main problem is in the "./"
> remove the "./"
> unless the file you want to remove are in the root

./ means the current directory.

take that out - you still reference the current directory.

$ touch abc
$ ls ./abc
./abc
$ ls abc
abc

they are the same file.

Using a full path is the best because you always know what it will be
referencing.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: unlink problems

2009-11-25T19:24:54Z

kesavan is right !!
i see the problem in link..

u type "./blabla.pdf" the main problem is in the "./"
remove the "./"
unless the file you want to remove are in the root

On 11/25/09, Kesavan Rengarajan <k7@...> wrote:

> Looks like the PDF is not in the admin directory. Try to use the full
> path to the PDF file and also check the permissions on the file.
>
> Sent from my iPhone
>
> On 25/11/2009, at 9:22 PM, Neil Jackson <neil@...> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>> I use the following to delete a file on a webserver
>>
>> if( unlink( "./$filename" ) )
>> {
>> echo $filename." deleted ";
>> $action='';
>> echo
>> "<script>document.location.href='$PHP_SELF?action=$action&code=
>> $code'</script>";
>> }
>>
>> But I get the following error
>> Warning: unlink(./6 November 2009.pdf): No such file or directory in
>> /srv/www/htdocs/bee_partners/admin/tenders.php on line 82 6 November
>> 2009.pdf not deleted
>>
>> Any help?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAksNBV4ACgkQGgk1S8edB3JqWgCfb61pxGvh+KCXNfNdWgF2kb/P
>> xCMAn2dSOgN9AiFYX35Ga00XyxZQwGnw
>> =NL6k
>> -----END PGP SIGNATURE-----
>>
>> --
>> PHP Database Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
akan ada dimana mulut terkunci dan suara tak ada lagi..
saat itu gunakanlah HP untuk melakukan SMS!!
-> ini aliran bedul.. bukan aliran aneh.
tertawa sebelum tertawa didepan RSJ..

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: unlink problems

2009-11-25T04:02:07Z

Looks like the PDF is not in the admin directory. Try to use the full
path to the PDF file and also check the permissions on the file.

Sent from my iPhone

On 25/11/2009, at 9:22 PM, Neil Jackson <neil@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> I use the following to delete a file on a webserver
>
> if( unlink( "./$filename" ) )
> {
> echo $filename." deleted ";
> $action='';
> echo
> "<script>document.location.href='$PHP_SELF?action=$action&code=
> $code'</script>";
> }
>
> But I get the following error
> Warning: unlink(./6 November 2009.pdf): No such file or directory in
> /srv/www/htdocs/bee_partners/admin/tenders.php on line 82 6 November
> 2009.pdf not deleted
>
> Any help?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iEYEARECAAYFAksNBV4ACgkQGgk1S8edB3JqWgCfb61pxGvh+KCXNfNdWgF2kb/P
> xCMAn2dSOgN9AiFYX35Ga00XyxZQwGnw
> =NL6k
> -----END PGP SIGNATURE-----
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

unlink problems

2009-11-25T02:19:35Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I use the following to delete a file on a webserver

if( unlink( "./$filename" ) )
{
echo $filename." deleted ";
$action='';
echo
"<script>document.location.href='$PHP_SELF?action=$action&code=$code'</script>";
}

But I get the following error
Warning: unlink(./6 November 2009.pdf): No such file or directory in
/srv/www/htdocs/bee_partners/admin/tenders.php on line 82 6 November
2009.pdf not deleted

Any help?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAksNBV4ACgkQGgk1S8edB3JqWgCfb61pxGvh+KCXNfNdWgF2kb/P
xCMAn2dSOgN9AiFYX35Ga00XyxZQwGnw
=NL6k
-----END PGP SIGNATURE-----

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: mySQL query syntax error

2009-11-14T04:35:18Z

I found the problem. The first subquery needed "AS" aliases. I am
learning more of what mySQL is capable of and appreciate the help. Ron

-----Original Message-----
From: TG <tg-php@...>
To: ron.piggott@...
Subject: Re: [PHP-DB] mySQL query syntax error
Date: Sat, 14 Nov 2009 07:17:53 -0500

Only half awake and don't really see the problem with customers.email since
you alias the two selects and union as 'customers'. But since you don't
have any other tables in your primary select, you can drop the
`customers` part and just say "ORDER BY email ASC".

----- Original Message -----
From: Ron Piggott <ron.piggott@...>
To: PHP DB <php-db@...>
Date: Sat, 14 Nov 2009 03:23:47 -0500
Subject: [PHP-DB] mySQL query syntax error

>
> I am getting the following error message:
>
> #1054 - Unknown column 'customers.email' in 'order clause'
>
> from the query below --- I don't understand why. Would someone help me
> please? Ron
>
>
> SELECT 'first_name', 'last_name', 'email'
> FROM (
>
> (
>
> SELECT `firstname` , `lastname` , `buyer_email`
> FROM `paypal_payment_info`
> WHERE `datecreation` = '$two_weeks_ago'
> GROUP BY `buyer_email`
> )
> UNION ALL (
>
> SELECT `mail_order_address`.`first_name` ,
> `mail_order_address`.`last_name` , `mail_order_address`.`email`
> FROM `mail_order_address`
> INNER JOIN `mail_order_payment` ON `mail_order_address`.`reference` =
> `mail_order_payment`.`mail_order_address_reference`
> WHERE `mail_order_payment`.`payment_received` = '$two_weeks_ago'
> GROUP BY `mail_order_address`.`email`
> )
> ) AS customers
> ORDER BY `customers`.`email` ASC
>
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

mySQL query syntax error

2009-11-14T00:23:46Z

I am getting the following error message:

#1054 - Unknown column 'customers.email' in 'order clause'

from the query below --- I don't understand why. Would someone help me
please? Ron

SELECT 'first_name', 'last_name', 'email'
FROM (

(

SELECT `firstname` , `lastname` , `buyer_email`
FROM `paypal_payment_info`
WHERE `datecreation` = '$two_weeks_ago'
GROUP BY `buyer_email`
)
UNION ALL (

SELECT `mail_order_address`.`first_name` ,
`mail_order_address`.`last_name` , `mail_order_address`.`email`
FROM `mail_order_address`
INNER JOIN `mail_order_payment` ON `mail_order_address`.`reference` =
`mail_order_payment`.`mail_order_address_reference`
WHERE `mail_order_payment`.`payment_received` = '$two_weeks_ago'
GROUP BY `mail_order_address`.`email`
)
) AS customers
ORDER BY `customers`.`email` ASC

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Join Multiply

2009-11-13T03:34:06Z

Check out my Multiply site

I set up a Multiply site with my pictures, videos and blog and I want
to add you as my friend so you can see it. First, you need to join
Multiply! Once you join, you can also create your own site and share
anything you want, with anyone you want.

Here's the link:
http://multiply.com/si/Q+8gUs9BkFj71dvZx2+5vA

Gampang Kerja Cepat Dapet Duit, Flexter Bisnis Online Dahsyat!!!Cepat
Dapat Jutaan
Pengen cepet dapet duit?? ayo gabung FLEXTER! Dapet PULSA MURAH, Dapet
DUIT CEPET!
Setiap member FLEXTER akan mendapat pulsa harga murah, bisa isi ulang
ke No HP sendiri dan ke No HP orang lain semua operator, setiap member
FLEXTER akan mendapatkan PELUANG BISNIS YANG LUAR BIASA dengan potensi
PENGHASILAN PASIF YANG TANPA BATAS!!
Bingung cara promosi? ga usah bingung anda tinggal gabung lewat
http://www.famsflex.com/?id=mulyani member datang sendiri pada anda,
karena kami memberi anda web pribadi untuk berpromosi secara online,
yang pastinya sangat membantu anda.
Pengen cepet dapet duit?? ayo gabung FLEXTER! Dapet PULSA MURAH, Dapet
DUIT CEPET!
Setiap member FLEXTER akan mendapat pulsa harga murah, bisa isi ulang
ke No HP sendiri dan ke No HP orang lain semua operator, setiap member
FLEXTER akan mendapatkan PELUANG BISNIS YANG LUAR BIASA dengan potensi
PENGHASILAN PASIF YANG TANPA BATAS!!
http://www.famsflex.com/?id=iwan
http://www.famsflex.com/?id=iwan
http://www.famsflex.com/?id=iwan
http://www.famsflex.com/?id=iwan
http://www.famsflex.com/?id=iwan

thx

Thanks,
iwan

Stop e-mails, view our privacy policy, or report abuse:
http://multiply.com/bl/Q+8gUs9BkFj71dvZx2+5vA
We haven't added your email address to any lists, nor will we share it
with anyone at any time.
Copyright 2009 Multiply Inc.
6001 Park of Commerce, Boca Raton, FL 33487, USA

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Multiple instances of mysql_connect() in single PHP document.

2009-11-12T13:52:56Z

Richard Quadling wrote:

> 2009/11/11 Chris <dmagick@...>:
>> Plus the assumption that they are on the same server and that the user
>> you're connecting with has access to both databases..
>
> See the initial post.
>
> $db_material = mysql_connect("localhost", "root", "secret");
> $db_labor = mysql_connect("localhost", "root", "secret");
>
> 2 connections using the same server and credentials - results in 1
> real connection.
>
> $db_material = mysql_connect("localhost", "root", "secret", true);
> $db_labor = mysql_connect("localhost", "root", "secret", true);
>
> should fix it.

Good pickup - the rest of us missed it :)

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: losing MySQL resource

2009-11-12T13:51:22Z

Stan wrote:

> I don't understand the process. When session_start() reconnects to a (the)
> session, objects saved as $_SESSION variables must be "recreated". To do
> this requires the class definition. So the class definition must be loaded
> prior to calling session_start().
>
>
>
> Some other languages I've written in had a process called serialization
> through which objects were saved. And an opposite (deserialization?)
> process through which objects were restored. To have "persistent" objects
> requires some way to "save" the objects for the next invocation of the
> application (PHP in this case). Deserialization necessarily requires the
> template upon which the original object was built (the class definition).
>
>
>
> I found http://us.php.net/serialize in the online PHP manual. I also found
> http://us.php.net/manual/en/language.oop5.autoload.php in the online PHP
> manual (I have not tried autoload).
>
>
>
> I simply moved the require_once("class_definitions.inc"); to appear
> immediately before my session_start(); and everything worked thereafter.

When data gets serialized in the session, it only stores the data itself
(public/private variables). It does not store the actual class (your
methods) and the code that makes it all work. That would just bloat the
session and cause other extra headaches.

So before the data can be properly loaded, you need the class.

http://us.php.net/manual/en/language.oop5.serialization.php

explains things a little better I hope.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Multiple instances of mysql_connect() in single PHP document.

2009-11-12T05:13:22Z

2009/11/11 Chris <dmagick@...>:
> Plus the assumption that they are on the same server and that the user
> you're connecting with has access to both databases..

See the initial post.

$db_material = mysql_connect("localhost", "root", "secret");
$db_labor = mysql_connect("localhost", "root", "secret");

2 connections using the same server and credentials - results in 1
real connection.

$db_material = mysql_connect("localhost", "root", "secret", true);
$db_labor = mysql_connect("localhost", "root", "secret", true);

should fix it.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Multiple instances of mysql_connect() in single PHP document.

2009-11-12T05:11:25Z

2009/11/11 Chris <dmagick@...>:

> Andy Shellam (Mailing Lists) wrote:
>>
>> Hi,
>>
>>>
>>> If the databases are in the same mysql server, then you could qualify
>>> the table select with the database name and simply re-use the
>>> connection
>>>
>>> select db_name.table_name.field from db_name.table_name [where]
>>
>> No offence, but if I saw this in an application's source code, I'd run a
>> mile.
>
> Plus the assumption that they are on the same server and that the user
> you're connecting with has access to both databases..
>
> --
> Postgresql & php tutorials
> http://www.designmagick.com/
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

If it comes to that, if you are writing SQL code in PHP rather than
abstracting it or using stored procedures/views/etc. ...

Essentially the issue is 2 identical connections are not actually 2
identical connections.

They are 2 references to a single connection.

So, changing the DB via 1 resource changes the db for both resources.

NOTE: IDENTICAL. If the server or username is different, then that
results in a separate connection.

<?php
$conn1 = mysql_connect($server, $username, $password);
$conn2 = mysql_connect($server, $username, $password); // Is the same
connection as $conn1
mysql_select_db($db1, $conn1); // Both connection resources are now
looking at db1.
mysql_select_db($db2, $conn2); // Both connection resources are now
looing at db2.

_ONE_ solution is to use fully qualified names (you can use constants
if you don't like hard-coding the db name in the query).

Another option is to set the new_link flag on the mysql_connect() call.

That way you will have 2 separate connections.

<?php
$conn1 = mysql_connect($server, $username, $password, true);
$conn2 = mysql_connect($server, $username, $password, true); // Is NOT
the same connection as $conn1
mysql_select_db($db1, $conn1); // Points to db1 for connection1
mysql_select_db($db2, $conn2); // Points to db2 for connection2

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: losing MySQL resource

2009-11-12T03:12:00Z

I don't understand the process. When session_start() reconnects to a (the)
session, objects saved as $_SESSION variables must be "recreated". To do
this requires the class definition. So the class definition must be loaded
prior to calling session_start().

Some other languages I've written in had a process called serialization
through which objects were saved. And an opposite (deserialization?)
process through which objects were restored. To have "persistent" objects
requires some way to "save" the objects for the next invocation of the
application (PHP in this case). Deserialization necessarily requires the
template upon which the original object was built (the class definition).

I found http://us.php.net/serialize in the online PHP manual. I also found
http://us.php.net/manual/en/language.oop5.autoload.php in the online PHP
manual (I have not tried autoload).

I simply moved the require_once("class_definitions.inc"); to appear
immediately before my session_start(); and everything worked thereafter.

"Nehemias Duarte" <NDuarte@...> wrote in message
news:2A10E35796E8A84FB782111FE5D3B30A03604B@......
I was under the impression that session_start() had to be the FIRST
thing ran in the script. Is this incorrect?

>>OK. The secret, as has been stated here before, is to load the class
definitions BEFORE calling session_start(). Thanks to everyone.

""Andy Shellam (Mailing Lists)"" <andy-lists@...> wrote in
message news:3339C510-BE08-4426-9265-BA1965A9ADDF@......

> Hi Stan,
>
> Are you saving the instance of your class in $_SESSION?
>
> Class instances can be persisted across sessions, however resources
> (i.e. MySQL and other DB connections) cannot. What you need to do, is
> every method in your wrapper class that uses the MySQL resource needs
> to check if it's a valid resource (is_resource() springs to mind.)
>
> If it isn't valid, you need to re-create it (using mysql_connect).
>
> The reason for this is that PHP isn't running between session
> requests, so it cannot maintain and monitor the database connection
> across requests.
>
> Andy
>
> On 9 November2009, at 21:11, Stan wrote:
>
> > I got as far as creating a class to be the wrapper ... instantiating
> > an
> > object of that class ... saving the reference in a $_SESSION
> > variable ...
> > but my object reference seems to be invalid upon the next request
> > (in the
> > same session) from the client browser. What have I missed?
> >
> > Thanks,
> > Stan
> >
> > ""Andy Shellam (Mailing Lists)"" <andy-lists@...> wrote

in
> > message news:FD8200B0-E18A-4AFD-8FFC-F51080621BB4@......
> >> Hi,
> >>
> >> I got around this by creating a database wrapper class which gets
> >> passed the credentials from the app's config file. An instance of
> >> the
> >> class is created and saved in the session, and every query to the
> >> database runs through the class's Query() wrapper method which
checks
> >> if the connection is alive and valid - if it isn't, it reconnects
it

> >> before running the query.
> >>
> >> Andy
> >>
> >> On 9 November2009, at 16:46, Stan wrote:
> >>
> >>> How do I make an Object persistant for the duration of a Session?
> >>> Thanks,
> >>> "Chris" <dmagick@...> wrote in message news:4AB6B16C.
> >>> 8@......
> >>>> Niel Archer wrote:
> >>>>>> I'm maintaining a session. I successfully connect to a

database
> >>> ($DBConnect
> >>>>>> = mysql_connect()). I save the connection resource in a
session

> >>> variable
> >>>>>> ($_SESSION['connection'] = $DBConnect) ... to use in subsequent
> >>> queries. It
> >>>>>> remains valid while the user is on the current page.
> >>>>>> print_r($_SESSION['connection']) yields 'Resource id #3', for
> >>>>>> instance.
> >>>>>>
> >>>>>> User browses to a new page ... in the same session.
> >>> $_SESSION['$DBConnect']
> >>>>>> no longer references a valid mysql resource.
> >>>>>> print_r($_SESSION['connection']) yields '0'.
> >>>>>>
> >>>>>> Other "ordinary" values saved in $_SESSION variables remain
> >>>>>> valid.
> >>>>>>
> >>>>>> Is there something special about a mysql resource?
> >>>>>
> >>>>> Not about the resource itself, no. PHP closes connections to a

Db
> >>>>> when a
> >>>>> script ends, unless the connection is persistent, so while the
> >>>>> resource
> >>>>> IS saved, the connection to which it refers no longer exists.
> >>>>
> >>>> No resources (whether they are persistent or not) can be stored
in

> >>>> the
> >>>> session.
> >>>>
> >>>> http://www.php.net/manual/en/intro.session.php
> >>>>
> >>>> The big pink box has more info.
> >>>>
> >>>> --
> >>>> Postgresql & php tutorials
> >>>> http://www.designmagick.com/
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Database Mailing List (http://www.php.net/)
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Confidentiality Notice:
This e-mail and any attachments may contain confidential information
intended solely for the use of the addressee. If the reader of this message
is not the intended recipient, any distribution, copying, or use of this
e-mail or its attachments is prohibited. If you received this message in
error, please notify the sender immediately by e-mail and delete this
message and any copies. Thank you.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php