On Wed, 2007-03-21 at 10:37 -0400, Mark wrote:
> Richard Lynch wrote:
>
> > On Tue, March 20, 2007 8:00 pm, Mark wrote:
> >
> > I'd agree with you, except now you've pulled the rug out and inserted
> > a 3rd party connection pool.
>
> That's not "pulling the rug out," that is a legitimate possib
Richard Lynch wrote:
> On Mon, March 19, 2007 10:58 pm, markw@mohawksoft.com wrote:
>>> markw@mohawksoft.com wrote:
> markw@mohawksoft.com wrote:
>>> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>>> Check the documentation - currval returns the last one *for that
>>> session* - it does n
Richard Lynch wrote:
> On Tue, March 20, 2007 8:00 pm, Mark wrote:
>
> I'd agree with you, except now you've pulled the rug out and inserted
> a 3rd party connection pool.
That's not "pulling the rug out," that is a legitimate possibility.
>
> Well, duh, if you're dumb enough to think you can
On Tue, March 20, 2007 8:00 pm, Mark wrote:
I'd agree with you, except now you've pulled the rug out and inserted
a 3rd party connection pool.
Well, duh, if you're dumb enough to think you can just slap it in and
everything will work by magic, you deserve what you get.
One would hope the connect
On Mon, March 19, 2007 10:58 pm, markw@mohawksoft.com wrote:
>> markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
>> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>> Check the documentation - currval returns the last one *for that
>> session* - it does not return the last global cha
Chris wrote:
> markw@mohawksoft.com wrote:
>>> markw@mohawksoft.com wrote:
> http://www.postgresql.org/docs/current/static/functions-sequence.html
>
> It is perfectly safe to use this.
In theory that may be true, but can the application developer make any
assumption about the
markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
http://www.postgresql.org/docs/current/static/functions-sequence.html
It is perfectly safe to use this.
In theory that may be true, but can the application developer make any
assumption about the underlying architecture? Might you be fami
Martin Marques wrote:
On Mon, 19 Mar 2007, Richard Lynch wrote:
The MySQL developers spent a zillion hours making the LAST_INSERT_ID()
function be tied to YOUR database connection.
You get *your* LAST_INSERT_ID(), not some random one from some other
database connection.
That's why http://php
> markw@mohawksoft.com wrote:
>>>
>>> http://www.postgresql.org/docs/current/static/functions-sequence.html
>>>
>>> It is perfectly safe to use this.
>>
>> In theory that may be true, but can the application developer make any
>> assumption about the underlying architecture? Might you be familiar w
On Mon, 19 Mar 2007, Richard Lynch wrote:
The MySQL developers spent a zillion hours making the LAST_INSERT_ID()
function be tied to YOUR database connection.
You get *your* LAST_INSERT_ID(), not some random one from some other
database connection.
That's why http://php.net/mysql_insert_id ta
On Mon, 2007-03-19 at 23:58 -0400, markw@mohawksoft.com wrote:
>
> I'm not a web developer. I suck at PHP, I do know PHP, I've written a
> number of PHP extensions, and have had my CVS account for about 8 years,
> but I'm not a web developer. I'm an architect and it is problematic when
> applicatio
markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
On Sat, 2007-03-17 at 12:19 -0400, Mark 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 Or
> markw@mohawksoft.com wrote:
>>> markw@mohawksoft.com wrote:
> On Sat, 2007-03-17 at 12:19 -0400, Mark 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 Oracl
On Sun, March 18, 2007 4:14 am, Jim Lucas 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.
> I too thought the same thing, but was corr
On Sat, March 17, 2007 1:08 pm, markw@mohawksoft.com 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.
Therein lies the biggest problem of mo
On Sat, March 17, 2007 11:19 am, Mark wrote:
> 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.
$query = "insert into the_table(...)";
mys
Chris wrote:
markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
On Sat, 2007-03-17 at 12:19 -0400, Mark 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
On Sat, March 17, 2007 10:16 am, Robert Cummings wrote:
> 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 increm
On Sat, March 17, 2007 9:43 am, 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? I assume if you
markw@mohawksoft.com wrote:
markw@mohawksoft.com wrote:
On Sat, 2007-03-17 at 12:19 -0400, Mark 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 PostgreS
- Original Message -
From:
I guess maybe most databases support the notion of "auto number" in some
form. I haven't used MSSQL recently, but I think their solution is a GUID.
You can set an auto-increment attribute on any integer data type. They also
have GUIDs, which they recome
> markw@mohawksoft.com wrote:
>>> On Sat, 2007-03-17 at 12:19 -0400, Mark 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.
> I too though
markw@mohawksoft.com 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_user
On Sat, 2007-03-17 at 14:08 -0400, markw@mohawksoft.com 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 dat
- Original Message -
From:
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 doo
> 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:
>>
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
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:
> >> >>
>
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)
>>
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_m
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_us
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
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 B
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
> starte
34 matches
Mail list logo
