Hi there, How (if) can i store the link from a mysql connect in a session
variable
something like
$_SESSION['db_link']=mysql_connect ( $server, $username, $password );
Currently de mysql link is not saved in the session ...while ather vars are
properly stored and retrieved ????
The goal of the exercise is to limit the amount of mysql_connect in my app.
Thnx,
Kees.
kees hessels wrote:
> Hi there, How (if) can i store the link from a mysql connect in a session
> variable
> something like
> $_SESSION['db_link']=mysql_connect ( $server, $username, $password );
>
> Currently de mysql link is not saved in the session ...while ather vars are
> properly stored and retrieved ????
> The goal of the exercise is to limit the amount of mysql_connect in my app.
You don't, there aren't any good effects of saving the resource in a session.
mysql_connect() results in a disconnect from the sql server when the
php-script has been run.
mysql_pconnect() tries to keep the connection alive, but still do not save the
resource to a session, as you never know if the connection will stay alive to
the next php-script, so you need to rerun the mysql_pconnect(), it will check
if the connection is still alive, is so it won't do anything else, but if it
would be so it's dead, then it will reconnect to the sql-server.
http://www.php.net/manual/en/function.mysql-pconnect.php
You will have as many mysql_pconnect() in your code as you did have
mysql_connect(), but you will have less overhead.
//Aho
My application is designed so that each user has his own database.
Is there a change that one user may be connecting to somebody elses
database?
"J.O. Aho"
news:48akh8Fh7e4eU1@individual.net...
> kees hessels wrote:
>> Hi there, How (if) can i store the link from a mysql connect in a session
>> variable
>> something like
>> $_SESSION['db_link']=mysql_connect ( $server, $username, $password );
>>
>> Currently de mysql link is not saved in the session ...while ather vars
>> are properly stored and retrieved ????
>> The goal of the exercise is to limit the amount of mysql_connect in my
>> app.
>
> You don't, there aren't any good effects of saving the resource in a
> session.
> mysql_connect() results in a disconnect from the sql server when the
> php-script has been run.
> mysql_pconnect() tries to keep the connection alive, but still do not save
> the resource to a session, as you never know if the connection will stay
> alive to the next php-script, so you need to rerun the mysql_pconnect(),
> it will check if the connection is still alive, is so it won't do anything
> else, but if it would be so it's dead, then it will reconnect to the
> sql-server.
>
> http://www.php.net/manual/en/function.mysql-pconnect.php
>
> You will have as many mysql_pconnect() in your code as you did have
> mysql_connect(), but you will have less overhead.
>
>
> //Aho
kees hessels wrote:
> My application is designed so that each user has his own database.
> Is there a change that one user may be connecting to somebody elses
> database?
As long as you define which database the user is supposed to connect in your
scripts, then there is no risk that they will get connected to the wrong one,
see to that the sql-user data is right
/* really simplified example */
switch($webuser) {
case "john":
$username = "mysql_john";
$password = "johnspassowrd";
$databasename = "johns_db";
break;
case "mary":
$username = "mysql_mary";
$password = "maryspassowrd";
$databasename = "marys_db";
break;
default:
exit;
break;
}
$resource=mysql_connect("localhost",$username,$password);
mysql_select_db($databasename,$resource);
Just use a function that checks who the logged in person is (from your session
data) and then use the right $username, $password and $databasename.
In the simplified example, only the one who us logged in as mary in the web
application will access the database assigned to mary and mary can't access
data in johns database (this is really restricted by the GRANT who has access
to what database/tables, http://dev.mysql.com/doc/refman/5.0/en/grant.html ).
Of course you can do more advanced ways to connect each user to the right
database without a need of a switch-case, everything depends on how you name
the databases, how you set database users/passwords (you could have one and
the same user/password for all the users databases, but that leads to the
downside that it would be possible to access others data with user defined SQL
statements, but your application may not allow this).
//Aho
Thanks AHO, I changed my app, and it works like it should again.
"J.O. Aho"
news:48aqekFjba7pU1@individual.net...
> kees hessels wrote:
>> My application is designed so that each user has his own database.
>> Is there a change that one user may be connecting to somebody elses
>> database?
>
> As long as you define which database the user is supposed to connect in
> your scripts, then there is no risk that they will get connected to the
> wrong one,
> see to that the sql-user data is right
>
> /* really simplified example */
>
> switch($webuser) {
> case "john":
> $username = "mysql_john";
> $password = "johnspassowrd";
> $databasename = "johns_db";
> break;
> case "mary":
> $username = "mysql_mary";
> $password = "maryspassowrd";
> $databasename = "marys_db";
> break;
> default:
> exit;
> break;
> }
>
> $resource=mysql_connect("localhost",$username,$password);
> mysql_select_db($databasename,$resource);
>
>
> Just use a function that checks who the logged in person is (from your
> session data) and then use the right $username, $password and
> $databasename.
> In the simplified example, only the one who us logged in as mary in the
> web application will access the database assigned to mary and mary can't
> access data in johns database (this is really restricted by the GRANT who
> has access to what database/tables,
> http://dev.mysql.com/doc/refman/5.0/en/grant.html ).
>
> Of course you can do more advanced ways to connect each user to the right
> database without a need of a switch-case, everything depends on how you
> name the databases, how you set database users/passwords (you could have
> one and the same user/password for all the users databases, but that leads
> to the downside that it would be possible to access others data with user
> defined SQL statements, but your application may not allow this).
>
>
> //Aho