A new version of the plugin has been released thanks to Andrew Donkin
who provided a variety of updates for the code. The updates include the
following changes -
- Removed the exists sub as it is not necessary when using an INSERT
with ON DUPLICATE KEY UPDATE.
- Removed the TOTALS insert an
On Monday, January 2, 2006 at 6:50:15 PM, [EMAIL PROTECTED] confabulated:
> You did have the latest version Duane.
> I guess MySQL 4.1 doesn't care if you have the "WHERE" clause after it;
> as I have been using the updated version for sometime and have not
> received any errors. But MySQL 5.0
You did have the latest version Duane.
I guess MySQL 4.1 doesn't care if you have the "WHERE" clause after it;
as I have been using the updated version for sometime and have not
received any errors. But MySQL 5.0, apparently, doesn't like that
syntax. I removed the WHERE clause and tested it
I am running MySQL 5.0 and WAS receiving an error for the SQL
statement that had the 'ON DUPLICATE KEY UPDATE'. After doing a little
investigation and looking into the MySQL docs I have fixed the issue.
I dropped the entire WHERE from the statement. According to MySQL
docs, there is
I have updated the INSERT code to use the "ON DUPLICATE KEY" feature of
MySQL. This feature insures that if the insert statement is executed
and another insert has already occurred for the changing day, an update
will take place instead. Hopefully, this will alleviate the largest
possibility of
Heute (28.12.2005/19:45 Uhr) schrieb Gary V ([EMAIL PROTECTED]),
>> > [OT] FYI, both 4.0 and 4.1 are available in Debian stable.
>>
>>do you know, which (maybe) problems by change of MySQL 4.1
>>becomes? Or not? I mean database errors and so on. I`ve heard of
>>password and charset mistakes.
>>--
> [OT] FYI, both 4.0 and 4.1 are available in Debian stable.
do you know, which (maybe) problems by change of MySQL 4.1
becomes? Or not? I mean database errors and so on. I`ve heard of
password and charset mistakes.
--
Viele Grüße, Kind regards,
Jim Knuth
Sorry Jim, I have not tried an upgrade
On Wed, Dec 28, 2005 at 02:19:51AM -0600, Chris Thielen wrote:
> James Keating wrote:
>
> >Well the simplest fix is the one that I did not implement in the first
> >place, using "ON DUPLICATE KEY". However, I did not implement that
> >because of its only being in version 4.1 of MySQL and I stil
James Keating wrote:
Well the simplest fix is the one that I did not implement in the first
place, using "ON DUPLICATE KEY". However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use
Debian stable for most production machines, which runs 4.0.x.
Anyw
Gary V wrote:
Well the simplest fix is the one that I did not implement in the first
place, using "ON DUPLICATE KEY". However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use
Debian stable for most production machines, which runs 4.0.x.
Anyway, I wi
Heute (28.12.2005/05:41 Uhr) schrieb Gary V ([EMAIL PROTECTED]),
>>Well the simplest fix is the one that I did not implement in the first
>>place, using "ON DUPLICATE KEY". However, I did not implement that because
>>of its only being in version 4.1 of MySQL and I still use Debian stable for
>
Well the simplest fix is the one that I did not implement in the first
place, using "ON DUPLICATE KEY". However, I did not implement that because
of its only being in version 4.1 of MySQL and I still use Debian stable for
most production machines, which runs 4.0.x.
Anyway, I will poke at it s
Well the simplest fix is the one that I did not implement in the first
place, using "ON DUPLICATE KEY". However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use Debian
stable for most production machines, which runs 4.0.x.
Anyway, I will poke at it s
On Tue, Dec 27, 2005 at 09:33:11PM -0500, James Keating wrote:
> Indeed. My thinking behind storing both system totals ($TOTALS) and user
> totals in the database was for easy error checking. Each day you can
> quickly/easily run through the database and look for potential errors
> (possibly re
Indeed. My thinking behind storing both system totals ($TOTALS) and user
totals in the database was for easy error checking. Each day you can
quickly/easily run through the database and look for potential errors
(possibly resulting from the race condition that you mentioned).
However, I have n
Neat plugin. I have two comments:
I wouldn't store $TOTALS or the total column in the database, as both
can easily be calculated when retrieving the data.
There is a race condition, especially for $TOTALS. First you check for
existence, then you try and do an insert or an update based on that. If
16 matches
Mail list logo
