php-general Digest 18 Mar 2007 09:14:12 -0000 Issue 4683
Topics (messages 250749 through 250769):
Re: Mail function undefined in PHP6
250749 by: Robert Cummings
250760 by: Tijnema !
Re: Getting last record ID created from DB
250750 by: Mark
250751 by: Colin Guthrie
250752 by: Colin Guthrie
250753 by: Mark
250754 by: Mark
250755 by: Myron Turner
250756 by: Robert Cummings
250758 by: Mark
250759 by: Robert Cummings
250761 by: Myron Turner
250762 by: markw.mohawksoft.com
250763 by: Satyam
250765 by: Robert Cummings
250769 by: Jim Lucas
form validation
250757 by: al phillips
Re: php +html mail
250764 by: Haydar TUNA
works at command line but not in apache
250766 by: rwhartung
250767 by: Tijnema !
glob(path_pattern, GLOB_ONLYDIR)
250768 by: Al
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Sat, 2007-03-17 at 11:07 +0100, Tijnema ! wrote:
> Hi,
>
> I have PHP6 installed (Snapshot:200703141130) and somehow it says now
> that the mail function is undefined, i have sendmail installed in /usr
> (is in $PATH)
> my configure command:
>
> './configure' '--prefix=/usr' '--with-pear' '--enable-all'
> '--with-apxs2' '--without-fbsql' '--without-interbase'
> '--without-mssql' '--with-mysql=/usr/mysql' '--with-msql=/usr/msql3'
> '--with-mysqli=/usr/mysql/bin/mysql_config' '--without-oci8'
> '--without-pdo-firebird' '--with-pdo-mysql=/usr/mysql'
> '--without-pdo-oci' '--without-pdo-odbc' '--with-pdo-pgsql=/usr/psql'
> '--with-pgsql=/usr/psql' '--without-sybase-ct' '--with-sybase'
> '--without-recode' '--without-informix' '--disable-mbregex'
> '--without-pdo-dblib'
>
> So, i don't see any reason why the mail function isn't build in...
You should probably field this question on internals since PHP6 doesn't
even have an alpha release yet to my knowledge.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
On 3/17/07, Robert Cummings <[EMAIL PROTECTED]> wrote:
On Sat, 2007-03-17 at 11:07 +0100, Tijnema ! wrote:
> Hi,
>
> I have PHP6 installed (Snapshot:200703141130) and somehow it says now
> that the mail function is undefined, i have sendmail installed in /usr
> (is in $PATH)
> my configure command:
>
> './configure' '--prefix=/usr' '--with-pear' '--enable-all'
> '--with-apxs2' '--without-fbsql' '--without-interbase'
> '--without-mssql' '--with-mysql=/usr/mysql' '--with-msql=/usr/msql3'
> '--with-mysqli=/usr/mysql/bin/mysql_config' '--without-oci8'
> '--without-pdo-firebird' '--with-pdo-mysql=/usr/mysql'
> '--without-pdo-oci' '--without-pdo-odbc' '--with-pdo-pgsql=/usr/psql'
> '--with-pgsql=/usr/psql' '--without-sybase-ct' '--with-sybase'
> '--without-recode' '--without-informix' '--disable-mbregex'
> '--without-pdo-dblib'
>
> So, i don't see any reason why the mail function isn't build in...
You should probably field this question on internals since PHP6 doesn't
even have an alpha release yet to my knowledge.
Cheers,
Rob.
Ok, i've forwarded the message to PHP-DEV
Tijnema
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Jeff wrote:
> Is there a way to get the last Record # created by the DB.
>
> Example:
>
> User_ID = auto_increment
> f_name = varchar
> l_name = varchar
> e-mail = varchar
> b_date = varchar
> pic = varchar
>
>
> Since user_id is an auto_inc field I submit it as a NULL, also I haven't
> started the code for a picture yet either so I have it set to NULL at this
> moment.
> My code is:
>
> $query = "INSERT INTO `t_users` (`user_id`, `f_name`, `l_name`, `e_mail`,
> `b_date`, `pic`) VALUES ('', '$f_name', '$l_name', '$e_mail', '$b_date',
> '')";
> $result = mysql_query($query);
> if(!$result)
> {
> die("Could not query the database: <br/>".mysql_error());
> }
> echo "Your Player information has been stored OK.<br />";
>
> what code could I add here to make the following line work?
>
> echo "REMEMBER your USER ID# you will need it when creating Characters!!
> It is: $user_id"; <----- I want to show the "user_id" just created here.
>
> Thanks in advance!
There are a couple ways to do this, it is presumed that there is some unique
field beyond just user id, for instance e_mail. Just select the id based on
email address.
It is typically bad form to rely on specifics of a particular SQL engine for
architecture.
The other way is, if you were using a real database, use a sequence. Select
next value from the sequence, and insert the row into t_users with id
already populated.
Last you could make user_id some sort of known unique number, like a GUID or
something where you can generte it in the web code and save yourself the
database hit.
--- End Message ---
--- Begin Message ---
Philip Thompson wrote:
> For auto increment values, you don't have to specify the id. For example:
>
> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
>
> Then to find the latest entry:
>
> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
This is not the cleanest way and some databases do not actually
increment auto id fields (e.g. they could fill in the blanks from
previous deletes etc.).
Much better is to use the function in the MySQL API to get the insert id
or if you really must use SQL, just run "SELECT LAST_INSERT_ID();" which
does much the same thing.
Col
--- End Message ---
--- Begin Message ---
Mark wrote:
>> select user_id from t_users where user_id = (select max(user_id) from
>> t_users)
>>
>
> It should be noted that that is the absolute 100% WRONG way to do it. If
> your site has any concurrency, you will almost certainly get the wrong
> user.
I agree 100% that it is 100% wrong, but just to point out something
blindingly obvious: it is also incredibly inefficient at being wrong!!
The sub-select selects the maximum user_id in the table. Fair enough.
This user_id is then fed into a statement that just returns that value
via a pointless lookup.
SELECT user_id from t_users WHERE user_id = 42;
Hmmmmm I wonder what user_id I'll get from that select....
Col.
--- End Message ---
--- Begin Message ---
Philip Thompson wrote:
> On Mar 16, 2007, at 10:28 PM, Jeff wrote:
>
>> Is there a way to get the last Record # created by the DB.
>>
>> Example:
>>
>> User_ID = auto_increment
>> f_name = varchar
>> l_name = varchar
>> e-mail = varchar
>> b_date = varchar
>> pic = varchar
>>
>>
>> Since user_id is an auto_inc field I submit it as a NULL, also I
>> haven't
>> started the code for a picture yet either so I have it set to NULL
>> at this
>> moment.
>> My code is:
>>
>> $query = "INSERT INTO `t_users` (`user_id`, `f_name`, `l_name`,
>> `e_mail`,
>> `b_date`, `pic`) VALUES ('', '$f_name', '$l_name', '$e_mail',
>> '$b_date',
>> '')";
>> $result = mysql_query($query);
>> if(!$result)
>> {
>> die("Could not query the database: <br/>".mysql_error());
>> }
>> echo "Your Player information has been stored OK.<br />";
>>
>> what code could I add here to make the following line work?
>>
>> echo "REMEMBER your USER ID# you will need it when creating
>> Characters!! It
>> is: $user_id"; <----- I want to show the "user_id" just created here.
>>
>> Thanks in advance!
>
>
> For auto increment values, you don't have to specify the id. For
> example:
>
> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
>
> Then to find the latest entry:
>
> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
>
> Hope that helps.
This too is almost certainly going to return the wrong user_id if the site
has any sort of concurrency. If in the time between the user creating an ID
and your code retrieving the ID, another user with another PHP process
could easily have executed the same insert.
--- End Message ---
--- Begin Message ---
Colin Guthrie wrote:
> Mark wrote:
>>> select user_id from t_users where user_id = (select max(user_id) from
>>> t_users)
>>>
>>
>> It should be noted that that is the absolute 100% WRONG way to do it. If
>> your site has any concurrency, you will almost certainly get the wrong
>> user.
>
> I agree 100% that it is 100% wrong, but just to point out something
> blindingly obvious: it is also incredibly inefficient at being wrong!!
>
> The sub-select selects the maximum user_id in the table. Fair enough.
> This user_id is then fed into a statement that just returns that value
> via a pointless lookup.
>
> SELECT user_id from t_users WHERE user_id = 42;
>
> Hmmmmm I wonder what user_id I'll get from that select....
>
Yea, I didn't see that little bit. My eyes saw max(user_id) and thought,
man, these guys should go to school or buy a book. I'm not talking anything
serious, just basic computer science 101.
I often wonder, looking at these questions, what is the state of the web? If
any notable percent of it is written with this much basic ignorance of
computing, then the web is basically broken.
--- End Message ---
--- Begin Message ---
Colin Guthrie wrote:
Philip Thompson wrote:
For auto increment values, you don't have to specify the id. For example:
INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
Then to find the latest entry:
SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
This is not the cleanest way and some databases do not actually
increment auto id fields (e.g. they could fill in the blanks from
previous deletes etc.).
Much better is to use the function in the MySQL API to get the insert id
or if you really must use SQL, just run "SELECT LAST_INSERT_ID();" which
does much the same thing.
Col
My own knowledge of mysql is about 5 years old and never really used.
But I was recently asked to do something that required some mysql
(noting too much, fortunately for me), so I've been doing some reading
and am interested in questions that come up on the list.
An earlier post called attention to a concurrency problem. Wouldn't
getting the last inserted ID from LAST_INSERT_ID()
suffer from the same limitations as any of the other solutions which do
a select to get the last ID? I assume if you are completely in control
of the database, you could create a lock file using flock() and remove
the lock once the Id is retrieved using any of these methods. I guess
what I'm wondering is whether the simplest suggestion is the one that
would use the email address as a condition in the WHERE clause to
extract the ID?
--
_____________________
Myron Turner
http://www.room535.org
http://www.bstatzero.org
http://www.mturner.org/XML_PullParser/
--- End Message ---
--- Begin Message ---
On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
> Colin Guthrie wrote:
> > Philip Thompson wrote:
> >
> >> For auto increment values, you don't have to specify the id. For example:
> >>
> >> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
> >> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
> >>
> >> Then to find the latest entry:
> >>
> >> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
> >>
> >
> > This is not the cleanest way and some databases do not actually
> > increment auto id fields (e.g. they could fill in the blanks from
> > previous deletes etc.).
> >
> > Much better is to use the function in the MySQL API to get the insert id
> > or if you really must use SQL, just run "SELECT LAST_INSERT_ID();" which
> > does much the same thing.
> >
> > Col
> >
> >
> My own knowledge of mysql is about 5 years old and never really used.
> But I was recently asked to do something that required some mysql
> (noting too much, fortunately for me), so I've been doing some reading
> and am interested in questions that come up on the list.
>
> An earlier post called attention to a concurrency problem. Wouldn't
> getting the last inserted ID from LAST_INSERT_ID()
> suffer from the same limitations as any of the other solutions which do
> a select to get the last ID?
No, it's a MySQL specific feature that is atomic with the insert and so
you are guaranteed that the the returned ID is the exact automatic ID
associated with the most recent INSERT for the connection handle.
Unfortunately auto increment is MySQL specific and so it isn't
transferrable to other database engines.
> I assume if you are completely in control
> of the database, you could create a lock file using flock() and remove
> the lock once the Id is retrieved using any of these methods.
You can, but locking is expensive, especial if there's a lot of activity
in the table.
> I guess what I'm wondering is whether the simplest suggestion is the one that
> would use the email address as a condition in the WHERE clause to
> extract the ID?
No.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
> On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
>> Colin Guthrie wrote:
>> > Philip Thompson wrote:
>> >
>> >> For auto increment values, you don't have to specify the id. For
>> >> example:
>> >>
>> >> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
>> >> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
>> >>
>> >> Then to find the latest entry:
>> >>
>> >> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
>> >>
>> >
>> > This is not the cleanest way and some databases do not actually
>> > increment auto id fields (e.g. they could fill in the blanks from
>> > previous deletes etc.).
>> >
>> > Much better is to use the function in the MySQL API to get the insert
>> > id or if you really must use SQL, just run "SELECT LAST_INSERT_ID();"
>> > which does much the same thing.
>> >
>> > Col
>> >
>> >
>> My own knowledge of mysql is about 5 years old and never really used.
>> But I was recently asked to do something that required some mysql
>> (noting too much, fortunately for me), so I've been doing some reading
>> and am interested in questions that come up on the list.
>>
>> An earlier post called attention to a concurrency problem. Wouldn't
>> getting the last inserted ID from LAST_INSERT_ID()
>> suffer from the same limitations as any of the other solutions which do
>> a select to get the last ID?
>
> No, it's a MySQL specific feature that is atomic with the insert and so
> you are guaranteed that the the returned ID is the exact automatic ID
> associated with the most recent INSERT for the connection handle.
> Unfortunately auto increment is MySQL specific and so it isn't
> transferrable to other database engines.
The problem is if the ID returned is not somehow linked to the transaction
which inserted the row. If you have an insert followed by a select to
retrieve the ID, in the interrum, another user may be created by another
process and you will retrieve the wrong ID.
If you have no users, it is unlikely, the more traffic your site has, the
more likely the problem. It is a *bad* design and any 1st year CS student
should know better.
>
>> I assume if you are completely in control
>> of the database, you could create a lock file using flock() and remove
>> the lock once the Id is retrieved using any of these methods.
>
> You can, but locking is expensive, especial if there's a lot of activity
> in the table.
MySQL locks too much already, one more lock won't hurt :-)
>
>> I guess what I'm wondering is whether the simplest suggestion is the one
>> that would use the email address as a condition in the WHERE clause to
>> extract the ID?
>
> No.
insert into the_table (..., email,..);
select user_id from the_table where email = '...';
Is probably the best way given the nature of the table and skill level of
the developer asking the question.
--- End Message ---
--- Begin Message ---
On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
> Robert Cummings wrote:
>
> > On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
> >> Colin Guthrie wrote:
> >> > Philip Thompson wrote:
> >> >
> >> >> For auto increment values, you don't have to specify the id. For
> >> >> example:
> >> >>
> >> >> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
> >> >> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
> >> >>
> >> >> Then to find the latest entry:
> >> >>
> >> >> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
> >> >>
> >> >
> >> > This is not the cleanest way and some databases do not actually
> >> > increment auto id fields (e.g. they could fill in the blanks from
> >> > previous deletes etc.).
> >> >
> >> > Much better is to use the function in the MySQL API to get the insert
> >> > id or if you really must use SQL, just run "SELECT LAST_INSERT_ID();"
> >> > which does much the same thing.
> >> >
> >> > Col
> >> >
> >> >
> >> My own knowledge of mysql is about 5 years old and never really used.
> >> But I was recently asked to do something that required some mysql
> >> (noting too much, fortunately for me), so I've been doing some reading
> >> and am interested in questions that come up on the list.
> >>
> >> An earlier post called attention to a concurrency problem. Wouldn't
> >> getting the last inserted ID from LAST_INSERT_ID()
> >> suffer from the same limitations as any of the other solutions which do
> >> a select to get the last ID?
> >
> > No, it's a MySQL specific feature that is atomic with the insert and so
> > you are guaranteed that the the returned ID is the exact automatic ID
> > associated with the most recent INSERT for the connection handle.
> > Unfortunately auto increment is MySQL specific and so it isn't
> > transferrable to other database engines.
>
> The problem is if the ID returned is not somehow linked to the transaction
> which inserted the row. If you have an insert followed by a select to
> retrieve the ID, in the interrum, another user may be created by another
> process and you will retrieve the wrong ID.
I don't believe this is an issue for MySQL. The last inserted ID isn't
stored for the database table, it's stored for the connection to the
database. As such there's no race condition unless the developer does
something silly, like issue another insert over the same connection
before requesting the previous last inserted id. Just to be sure though
the following is from the MySQL online documentation:
::::
For LAST_INSERT_ID(), the most recently generated ID is maintained in
the server on a per-connection basis. It is not changed by another
client. It is not even changed if you update another AUTO_INCREMENT
column with a non-magic value (that is, a value that is not NULL and not
0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously
from multiple clients is perfectly valid. Each client will receive the
last inserted ID for the last statement that client executed.
::::
http://dev.mysql.com/doc/refman/5.0/en/getting-unique-id.html
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
An earlier post called attention to a concurrency problem. Wouldn't
getting the last inserted ID from LAST_INSERT_ID()
suffer from the same limitations as any of the other solutions which do
a select to get the last ID?
No, it's a MySQL specific feature that is atomic with the insert and so
you are guaranteed that the the returned ID is the exact automatic ID
associated with the most recent INSERT for the connection handle.
Unfortunately auto increment is MySQL specific and so it isn't
transferrable to other database engines.
The problem is if the ID returned is not somehow linked to the transaction
which inserted the row. If you have an insert followed by a select to
retrieve the ID, in the interrum, another user may be created by another
process and you will retrieve the wrong ID.
I don't believe this is an issue for MySQL. The last inserted ID isn't
stored for the database table, it's stored for the connection to the
database. As such there's no race condition unless the developer does
something silly, like issue another insert over the same connection
before requesting the previous last inserted id. Just to be sure though
the following is from the MySQL online documentation:
::::
For LAST_INSERT_ID(), the most recently generated ID is maintained in
the server on a per-connection basis. It is not changed by another
client. It is not even changed if you update another AUTO_INCREMENT
column with a non-magic value (that is, a value that is not NULL and not
0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously
from multiple clients is perfectly valid. Each client will receive the
last inserted ID for the last statement that client executed.
::::
http://dev.mysql.com/doc/refman/5.0/en/getting-unique-id.html
Cheers,
Rob.
Thanks. Very interesting, and makes a lot of sense.
--
_____________________
Myron Turner
http://www.room535.org
http://www.bstatzero.org
http://www.mturner.org/XML_PullParser/
--- End Message ---
--- Begin Message ---
> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>> Robert Cummings wrote:
>>
>> > On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
>> >> Colin Guthrie wrote:
>> >> > Philip Thompson wrote:
>> >> >
>> >> >> For auto increment values, you don't have to specify the id. For
>> >> >> example:
>> >> >>
>> >> >> INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
>> >> >> VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
>> >> >>
>> >> >> Then to find the latest entry:
>> >> >>
>> >> >> SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
>> >> >>
>> >> >
>> >> > This is not the cleanest way and some databases do not actually
>> >> > increment auto id fields (e.g. they could fill in the blanks from
>> >> > previous deletes etc.).
>> >> >
>> >> > Much better is to use the function in the MySQL API to get the
>> insert
>> >> > id or if you really must use SQL, just run "SELECT
>> LAST_INSERT_ID();"
>> >> > which does much the same thing.
>> >> >
>> >> > Col
>> >> >
>> >> >
>> >> My own knowledge of mysql is about 5 years old and never really used.
>> >> But I was recently asked to do something that required some mysql
>> >> (noting too much, fortunately for me), so I've been doing some
>> reading
>> >> and am interested in questions that come up on the list.
>> >>
>> >> An earlier post called attention to a concurrency problem. Wouldn't
>> >> getting the last inserted ID from LAST_INSERT_ID()
>> >> suffer from the same limitations as any of the other solutions which
>> do
>> >> a select to get the last ID?
>> >
>> > No, it's a MySQL specific feature that is atomic with the insert and
>> so
>> > you are guaranteed that the the returned ID is the exact automatic ID
>> > associated with the most recent INSERT for the connection handle.
>> > Unfortunately auto increment is MySQL specific and so it isn't
>> > transferrable to other database engines.
>>
>> The problem is if the ID returned is not somehow linked to the
>> transaction
>> which inserted the row. If you have an insert followed by a select to
>> retrieve the ID, in the interrum, another user may be created by another
>> process and you will retrieve the wrong ID.
>
> I don't believe this is an issue for MySQL. The last inserted ID isn't
> stored for the database table, it's stored for the connection to the
> database. As such there's no race condition unless the developer does
> something silly, like issue another insert over the same connection
> before requesting the previous last inserted id. Just to be sure though
> the following is from the MySQL online documentation:
>
> ::::
> For LAST_INSERT_ID(), the most recently generated ID is maintained in
> the server on a per-connection basis. It is not changed by another
> client. It is not even changed if you update another AUTO_INCREMENT
> column with a non-magic value (that is, a value that is not NULL and not
> 0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously
> from multiple clients is perfectly valid. Each client will receive the
> last inserted ID for the last statement that client executed.
> ::::
>
> http://dev.mysql.com/doc/refman/5.0/en/getting-unique-id.html
>
> Cheers,
> Rob.
> --
There in lies the biggest problem with LAMP, and that's MySQL. The
architecture of your methodology *only* works with MySQL, and not more
capable databases like Oracle, DB2, or even PostgreSQL.
If you rely on oddities of a particular system, then you are doomed to be
stuck with it or pay the price of redesign when you need a more capable
system.
--- End Message ---
--- Begin Message ---
----- Original Message -----
From: <[email protected]>
There in lies the biggest problem with LAMP, and that's MySQL. The
architecture of your methodology *only* works with MySQL, and not more
capable databases like Oracle, DB2, or even PostgreSQL.
If you rely on oddities of a particular system, then you are doomed to be
stuck with it or pay the price of redesign when you need a more capable
system.
Not so much. Most databases offer some sort of autoincrementing integer and
a means to get its value immediately after an insert. The syntax both for
creating it and retrieving it might vary, but it exists in some form or
other. This does not excuse the overuse of autonumerics as primary keys
and most often, the only key in a whole table. Significant keys, that is,
keys that are meaningful for the data being stored, are far more valuable if
they exist.
Satyam
--- End Message ---
--- Begin Message ---
On Sat, 2007-03-17 at 14:08 -0400, [email protected] wrote:
> > On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
> >> Robert Cummings wrote:
>
> There in lies the biggest problem with LAMP, and that's MySQL. The
> architecture of your methodology *only* works with MySQL, and not more
> capable databases like Oracle, DB2, or even PostgreSQL.
>
> If you rely on oddities of a particular system, then you are doomed to be
> stuck with it or pay the price of redesign when you need a more capable
> system.
I'd have to disagree, I'm currently working on largish project and an
intentional decision was made to use the auto incrementing feature of
MySQL for better speed. To move away from the MySQL auto increment
feature in the future is as simple as changing code in one location.
Many people using MySQL do so for a reason, to then discard the
advantages of the chosen system should be weighed carefully against
future expectations. Also, oddity implies a negative perspective, one
man's oddity is another man's feature. I'm quite certain the developers
at MySQL implemented auto increment as a feature to simplify the lives
of developers working with databases.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
[email protected] wrote:
On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
Robert Cummings wrote:
On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
Colin Guthrie wrote:
Philip Thompson wrote:
For auto increment values, you don't have to specify the id. For
example:
INSERT INTO t_users (f_name, l_name, e_mail, b_date, pic)
VALUES ('$f_name', '$l_name', '$e_mail', '$b_date', null);
Then to find the latest entry:
SELECT user_id FROM t_users ORDER BY user_id DESC limit 1;
This is not the cleanest way and some databases do not actually
increment auto id fields (e.g. they could fill in the blanks from
previous deletes etc.).
Much better is to use the function in the MySQL API to get the
insert
id or if you really must use SQL, just run "SELECT
LAST_INSERT_ID();"
which does much the same thing.
Col
My own knowledge of mysql is about 5 years old and never really used.
But I was recently asked to do something that required some mysql
(noting too much, fortunately for me), so I've been doing some
reading
and am interested in questions that come up on the list.
An earlier post called attention to a concurrency problem. Wouldn't
getting the last inserted ID from LAST_INSERT_ID()
suffer from the same limitations as any of the other solutions which
do
a select to get the last ID?
No, it's a MySQL specific feature that is atomic with the insert and
so
you are guaranteed that the the returned ID is the exact automatic ID
associated with the most recent INSERT for the connection handle.
Unfortunately auto increment is MySQL specific and so it isn't
transferrable to other database engines.
The problem is if the ID returned is not somehow linked to the
transaction
which inserted the row. If you have an insert followed by a select to
retrieve the ID, in the interrum, another user may be created by another
process and you will retrieve the wrong ID.
I don't believe this is an issue for MySQL. The last inserted ID isn't
stored for the database table, it's stored for the connection to the
database. As such there's no race condition unless the developer does
something silly, like issue another insert over the same connection
before requesting the previous last inserted id. Just to be sure though
the following is from the MySQL online documentation:
::::
For LAST_INSERT_ID(), the most recently generated ID is maintained in
the server on a per-connection basis. It is not changed by another
client. It is not even changed if you update another AUTO_INCREMENT
column with a non-magic value (that is, a value that is not NULL and not
0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously
from multiple clients is perfectly valid. Each client will receive the
last inserted ID for the last statement that client executed.
::::
http://dev.mysql.com/doc/refman/5.0/en/getting-unique-id.html
Cheers,
Rob.
--
There in lies the biggest problem with LAMP, and that's MySQL. The
architecture of your methodology *only* works with MySQL, and not more
capable databases like Oracle, DB2, or even PostgreSQL.
I too thought the same thing, but was corrected when I starting working
on a redesign for the billing system for the company that I am working
for. They use PostgreSQL and we do have a auto incremented unique id
field. It isn't call AUTO_INCREMENT, but rather a sequence value. It
is a value that is controlled by the default value entry.
It then runs this:
nextval('customers_customer_id_seq'::regclass)
and uses this as the value of the id field for the newly inserted row.
Then instead of running a command like SELECT LAST_INSERT_ID(); you have
to do some other stuff like this:
$SQL = "SELECT currval('{$table}_{$column}_seq');";
If you rely on oddities of a particular system, then you are doomed to be
stuck with it or pay the price of redesign when you need a more capable
system.
--- End Message ---
--- Begin Message ---
I found the error in my previous question about parse just a simple ; at the
end.
I'm trying to validate some textfields especially name fields and email
addresses. I'm having a little trouble writing the code using classes and
regular expressions? I would like to validate the input from server side
scripting. If anyone has any examples or guidelines when writing a function or
a if statement I would gladly welcome an outside opinion.
Sincerely,
---------------------------------
Don't get soaked. Take a quick peek at the forecast
with theYahoo! Search weather shortcut.
--- End Message ---
--- Begin Message ---
Hello,
If you are new to php or other web technologies, you can find many
information,examples about PHP and other web technologies in
http://www.w3schools.com/ web sites. This is a great web site for web
technology education. :)
--
Haydar TUNA
Republic Of Turkey - Ministry of National Education
Education Technology Department Ankara / TURKEY
Web: http://www.haydartuna.net
""Wasantha De Silva"" <[EMAIL PROTECTED]>, haber iletisinde sunlari
yazdi:[EMAIL PROTECTED]
Dear all,
I want get a help from you for some php codes.
How can I get it.
Regards
wasantha
--- End Message ---
--- Begin Message ---
Hi,
I have this short php script: [op;ening <?php and closing ?> removed.
$db = pg_connect('dbname=bpsimple user=minitwr password=RWHart') ;
print $db . "<br />" . "\n" ;
if ($db)
{
print 'Connection attempt succeeded.' . "<br />" . "\n" ;
} else
{
print 'Connection attempt failed.'. "<br />" . "\n" ;
}
$query = 'SELECT fname, lname FROM customer' ;
$result = pg_query($db, $query) ;
while($myrow = pg_fetch_assoc($result) )
{
print $myrow['fname'] . " " . $myrow['lname'] . "\n" ;
}
This works fine as a PHP script from the command line, but wrapped up in
<html> </html> tags it refuses to connect with the database from within
apache. All connections are local host. PHP otherwise works fine on
the apache server and the code is identical on both the CL script and
the test.php web page. Ideas? Where to start looking?
TIA
Bob
--- End Message ---
--- Begin Message ---
On 3/17/07, rwhartung <[EMAIL PROTECTED]> wrote:
Hi,
I have this short php script: [op;ening <?php and closing ?> removed.
$db = pg_connect('dbname=bpsimple user=minitwr password=RWHart') ;
print $db . "<br />" . "\n" ;
if ($db)
{
print 'Connection attempt succeeded.' . "<br />" . "\n" ;
} else
{
print 'Connection attempt failed.'. "<br />" . "\n" ;
}
$query = 'SELECT fname, lname FROM customer' ;
$result = pg_query($db, $query) ;
while($myrow = pg_fetch_assoc($result) )
{
print $myrow['fname'] . " " . $myrow['lname'] . "\n" ;
}
This works fine as a PHP script from the command line, but wrapped up in
<html> </html> tags it refuses to connect with the database from within
apache. All connections are local host. PHP otherwise works fine on
the apache server and the code is identical on both the CL script and
the test.php web page. Ideas? Where to start looking?
TIA
Bob
One of the comments in the PHP Manual says this:
If you use pg_connect('host=localhost port=5432 user=my_username
password=my_password dbname=my_dbname') and you get the following
error:
"Warning: pg_connect(): Unable to connect to PostgreSQL server: could
not connect to server: Connection refused Is the server running on
host localhost and accepting TCP/IP connections on port 5432?"
then you should try to leave the host= and port= parts out of the
connection string. This sounds strange, but this is an "option" of
Postgre. If you have not activated the TCP/IP port in postgresql.conf
then postgresql doesn't accept any incoming requests from an TCP/IP
port. If you use host= in your connection string you are going to
connect to Postgre via TCP/IP, so that's not going to work. If you
leave the host= part out of your connection string you connect to
Postgre via the Unix domain sockets, which is faster and more secure,
but you can't connect with the database via any other PC as the
localhost.
I think that's what your problem is also, but not sure about it.
(using MySQL mostly)
Tijnema
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I can't use flag "GLOB_ONLYDIR" to work on a Linux, php4.4.4. I only want the
dirs.
This works; sort of:
print_r(glob('../*',)); //It lists all the files AND directories. Yet it seems
to ignore the lack of ".*" and finds xxx.yyy. That's OK, I can delete the files
This fails:
print_r(glob('../*', GLOB_ONLYDIR));
And I get: "Warning: glob() expects parameter 2 to be long, string given in foo"
I can't find anything in the manual or when Googling.
Anyone can explain this for me?
--- End Message ---
