On Dec 8, 2004, at 9:12 AM, Jay Ess wrote:
I am not using cross database updates. It is all on one database but
the update uses two tables.
The query "update content_review_site as a,site_rating_factors as b
set a.overall_rating = 77 where a.content_id=243" is a stripped down
version of a bigger
Eric Bergen wrote:
Jay,
Are you using the replicate-do-db option on the slave? This option
relies on 'use' being set correctly when the query is issued. A quote
from the manual explains it better than I can:
"Tells the slave to restrict replication to statements where the
default database (that i
Jay,
Are you using the replicate-do-db option on the slave? This option
relies on 'use' being set correctly when the query is issued. A quote
from the manual explains it better than I can:
"Tells the slave to restrict replication to statements where the
default database (that is, the one selecte
I have a problem with an update query not replicating through to the slave.
The query is "update content_review_site as a,site_rating_factors as b set
a.overall_rating = 77 where a.content_id=243"
Version : 4.0.22
OS : Linux X86
How to replicate the error.
CREATE TABLE content_review_site (
con
At 9:45 -0600 3/8/03, Mark Matthews wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Description:
It is unbelievable that the MySQL ver 4.0 have so many bug, I
have been reported 2 bugs just a few days ago.
Now, I have found a bug again.
The bug is :
When I execute
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Description:
It is unbelievable that the MySQL ver 4.0 have so many bug, I have been
reported 2 bugs just a few days ago.
Now, I have found a bug again.
The bug is :
When I execute "select * from old_topic where FID=4 and (
ry NOT NULL default '',
`replytime` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`MGID`),
KEY `uid` (`uid`),
KEY `FID` (`FID`,`page`,`replytime`),
FULLTEXT KEY `topic` (`topic`)
) TYPE=MyISAM
>How-To-Repeat:
>Fix:
>Sub
ply` smallint(5) unsigned NOT NULL default '0',
`last_replyer` char(20) binary NOT NULL default '',
`replytime` datetime NOT NULL default '-00-00 00:00:00',
PRIMARY KEY (`MGID`),
KEY `uid` (`uid`),
KEY `FID` (`FID`,`page`),
KEY `FID_2` (`FID`,`replytime`),
FULLTEX
I am using mysql 3.23.41 and I discovered this bug.
Imagine you have a varchar column named nick.
If you send this query it correctly fails:
select * from users where nick = 0;
because data types are different but if you issue this one:
update users set psw = "mypsw" where nick = 0;
it modifies al
On Wed, Jul 04, 2001 at 07:16:50PM -0500, [EMAIL PROTECTED] wrote:
> Ok, I know I submitted an earlier bug report about this, but I've
> actually had it happen from the mysql monitor. Essentially, UPDATE
> queries are executing, but not actually updating, unless I SELECT
> data from the table fir
>Description:
Ok, I know I submitted an earlier bug report about this, but I've actually
had it happen from the mysql monitor. Essentially, UPDATE queries are
executing, but not actually updating, unless I SELECT data from the table
first.
>How-To-Repeat:
Simple as that. I have ye
Hi,
regarding
http://ep33.tp4.ruhr-uni-bochum.de/mlists/MySQL/May.2000/index.html#2025 , I
had the same problem with MySQL 3.23.30.
The following statement "Update Tree set left=left+2 where (left>$right and
right>=$right);" sometimes (not reproducable) locked up MySQL completely.
The "left" valu
wxrwxrwx 1 root wheel 9 Mar 13 12:02 /usr/lib/libc.so -> libc.so.4
> -r--r--r-- 1 root wheel 559196 Nov 20 2000 /usr/lib/libc.so.4
> Configure command: ./configure --localstatedir=/var/db/mysql --without-perl
>--without-debug --without-readline --without-bench --with-mit-threads=
>Description:
When updating a table after it has been selected with a LEFT JOIN, some
UPDATE queries execute normally without actually updating the data, unless the
data to be updated is selected normally first.
This script is written in mod_perl, using DBI::mysql to connect to the
On 2001 Apr 13, Maciek Dobrzanski <[EMAIL PROTECTED]> wrote:
> > This is because with the first query it can use the index. With
> > the second query, it has to check the whole table. Why? Because
> > obviously you're using numbers. And let's make some_value == 10.
>
> I thought that maybe My
> This is because with the first query it can use the index. With
> the second query, it has to check the whole table. Why? Because
> obviously you're using numbers. And let's make some_value == 10.
I thought that maybe MySQL should check the field type and do the conversion
to string.
--
On 2001 Apr 13, Maciek Dobrzanski <[EMAIL PROTECTED]> wrote:
> | fd_10 | varchar(20) | | MUL | | |
> | fd_11 | varchar(20) | | | | |
>
> Now when I do this update:
> UPDATE test SET fd_11='value' WHERE fd_10='some_value'
> it usu
Hi,
There might be some kind of bug in UPDATE. Let's say there is a 4 row
table, which looks like this:
| fd_01 | int(11) unsigned | | PRI | 0 | |
| fd_02 | text | | | | |
| fd_03 | varchar(4) | | |
Actually I have 2.23.20-gamma and I get 'create dabase blabla' in my update log.
cheers,
thalis
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
> Hi,
>
> Can you guys confirm that "create database" statements are not logged in
> the log-update log? The version I am using is 3.22.32.
>
>
> Rega
Hi,
Can you guys confirm that "create database" statements are not logged in
the log-update log? The version I am using is 3.22.32.
Regards,
Jerry.
-
Before posting, please check:
http://www.mysql.com/manual.php (the ma
20 matches
Mail list logo
