I am comparing two tables, domains and temp, to find records with a field that
has been modified. I create the temp table with
create table temp like domains;
then [eventually] create a table t3 that contains the domain name of any record
that does not match. My question is about 'natural
The natural join will JOIN on *all* the fields whose names match, not just the
ones you want it to.
In particular, the JOIN is matching up .expires and .expires with =
You then use WHERE to get only the ones with
This is a tautology: There are NO records both = and on the field
Thank you.
On Wed, 21 Jan 2009, c...@l-i-e.com wrote:
The natural join will JOIN on *all* the fields whose names match, not just the
ones you want it to.
In particular, the JOIN is matching up .expires and .expires with =
You then use WHERE to get only the ones with
This is a tautology:
Why are A and B letting you cram NULL into a column declared NOT NULL?
Are your schemas consistent on A/B/C?
Perhaps 5.0.32 does not enforce NOT NULL properly?
Some tweak to config may change this?
I don't know the answer, but with a bit of research in this direction, you
should be
Is the sql_mode set the same on A/B/C?
Why are A and B letting you cram NULL into a column declared NOT NULL?
Are your schemas consistent on A/B/C?
Perhaps 5.0.32 does not enforce NOT NULL properly?
Some tweak to config may change this?
I don't know the answer, but with a bit of
Yes, sql_mode is blank on all server A, B, C
On Wed, Jan 21, 2009 at 8:40 PM, John Daisley
john.dais...@mypostoffice.co.uk wrote:
Is the sql_mode set the same on A/B/C?
Why are A and B letting you cram NULL into a column declared NOT NULL?
Are your schemas consistent on A/B/C?
I think maybe in the default sql_mode 5.0 is more forgiving when it comes
to accepting invalid values, quietly converting them to the nearest
acceptable value and giving a warning whereas 5.1 gives an error.
Personally i would rather have the data rejected and an error returned
because if MySQL
On Wed, 2009-01-21 at 13:36 +0800, mik...@qualityadvantages.com wrote:
Hello mysql,
I would like to run a PHP script to perform a CRON Database backup to
avoid passing database credentials to the CRON process. Does this make
sense?
What are the recommended MySQLDump options that should
Thanks to Donna for that very useful SQL statement. Below is the script
I ended up writing to clean the eight-bajillion eventum_* tables that
accidentally got splattered into our servers.
Anyways, this is probably very useful for other types of bulk SQL stuff
via some BASH scripting so I figured
You need to consider things like how you plan to carry out recovery in
the event of a failure and portability, then choose options which best
meet your needs. You don't really want to go trying someone else's
settings without knowing exactly what output you are going to produce
and whether that
On Wed, Jan 21, 2009 at 12:36 AM, mik...@qualityadvantages.com wrote:
Hello mysql,
I would like to run a PHP script to perform a CRON Database backup to
avoid passing database credentials to the CRON process. Does this make
sense?
I'm not sure what your question about this is, but: if you
Didn't want this to go unanswered, although I don't have any great info for you.
As long as you're running a 64-bit OS and a 64-bit version of MySQL,
there's no technical reason it would be limited to less than the
addressable space (that I know of). The main gain would be the ability
to set
I have seen testing of servers up to 128 GB of RAM. I wish I could say I
was the one doing the test..however I use systems on a regular basis with
up to 32 GB. Does it scale perfectly? No. Is it better than it was just a
year ago even? Definitely.
Hope that helps.
Keith Murphy
Didn't want
Anyone?
I'm trying to diagnose this and not having much luck. I can't even
figure out where to even begin to look. I have two MySQL servers and
getting different results for the same query on both:
SERVER 1:
mysqladmin Ver 8.41 Distrib 5.0.37, for pc-linux-gnu on i686
You might try explicitly formatting your date as the string-type you
are expecting, but it looks to me like it should wokr exactly as you
have it. I would agree with your suspicion about your v5.0.37. It
worked fine as you wrote it on my v5.0.45, although it reported 2 rows
affected on each
Michael Dykman wrote:
It
worked fine as you wrote it on my v5.0.45, although it reported 2 rows
affected on each subsequent run of the insert statement. I thought
this odd as I only ran the same statement repeatedly leaving me with
one row ever, but the value updated just fine.
I noticed
Hi John,
Actaually, after doing root cause analysis. I got where is the problem.
mysql-5.1.30 (server C) runs replication in two mode namely STRICT and
IDEMPOTANT. Both of these mode is catching the problem.
I believe replicaton has been enhanced on mysql version 5.1.30 . When ever
any update is
17 matches
Mail list logo
