Blatantly assuming you are using PuTTy because of your question:
click-and-drag the mouse to select text. Then, press Shift+Ctrl+C to
copy to the clipboard. Press Shift+Ins to insert text back into the
console at the current carot-position.
Hope that helps..
Walter Heck
On Thu, May 14, 2009
On Thu, May 14, 2009 at 7:01 PM, Douglas Nelson wrote:
> try running the command like this
>
> select * from user where user='root' \G
>
> Capital G is a must.
I did the following:
[r...@mysql ~]# /etc/init.d/mysqld stop
Stopping MySQL:[ OK ]
[r...@
On Thu, May 14, 2009 at 7:06 PM, Carlos Proal wrote:
>
> The machine mysql.unixslut.com is not the same than localhost, right ??,
> If you only need root access from localhost you can delete the first row
> (delete from user where user='root' and host='mysql.unixslut.com';)
Carlos,
Yes, my mach
"I've run up on the rock of a binary (meaning: indecipherable) field."
SELECT hex(some_binary_field) FROM table;
Solved.
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of
A MAC address is just a number, it doesn't contain letters unless you're doing
something silly like storing the HEX representation of it. Do not use CHAR!
This does DOUBLE for all of you storing IP addresses!
Since a MAC address is going to be between 48 and 64 bits, then BIGINT is
appropria
Thanks all who replied.
After I posted I kept looking and found it... Also had folks point it
out to me.
Your suggestion is what I ended up doing.
Bruce
Gavin Towey wrote:
> Hi Bruce,
>
>
>
> SELECT … INTO OUTFILE always creates the file local to the database
> server. If you want to dum
Hi Bruce,
SELECT ... INTO OUTFILE always creates the file local to the database server.
If you want to dump results where your perl script is running you'll have to
use another method such as receiving the results of the query normally and
writing the file in the perl script.
Regards,
Ga
David,
The only metric is "as big as it needs to be."
Personally I recommend setting innodb-file-per-table in the my.cnf, then
configuring the ibdata file to be some small size, with the autoextend option
enabled. That way it will take up only as much space as it needs, you'll be
able to re
On Thu, May 14, 2009 at 7:41 PM, jean claude babin wrote:
> Hello,
>
> I'm pretty new in MySql. I would like to know how you can copy a statement
> like
> mysql> INSERT INTO customers ( firstname, surname, title, phone) values (
> 'Jhon', 'Campbell', 'Mr', 345 987 5500)
> in the MySql console in
On May 12, 2009, at 11:11 PM, Simon J Mudd wrote:
talkli...@newgeo.com (Scott Haneda) writes:
Hello, I am confused about repliction setup. Reading a config file,
and the docs, leads me to believe this is an either code choice, pick
#1 or #2. If that is the case, why would I want to use #1 ov
Hello,
I'm pretty new in MySql. I would like to know how you can copy a statement
like
mysql> INSERT INTO customers ( firstname, surname, title, phone) values (
'Jhon', 'Campbell', 'Mr', 345 987 5500)
in the MySql console in order to avoid typing it each time you want to fill
a new record.
I tri
Carlos Proal wrote:
>
> The machine mysql.unixslut.com is not the same than localhost, right ??,
> If you only need root access from localhost you can delete the first
> row (delete from user where user='root' and host='mysql.unixslut.com';)
>
>
> Carlos
>
>
> On 5/14/2009 5:55 PM, Carlos Williams
The machine mysql.unixslut.com is not the same than localhost, right ??,
If you only need root access from localhost you can delete the first row
(delete from user where user='root' and host='mysql.unixslut.com';)
Carlos
On 5/14/2009 5:55 PM, Carlos Williams wrote:
On Thu, May 14, 2009 at
try running the command like this
select * from user where user='root' \G
Capital G is a must.
thanks Doug
Carlos Williams wrote:
On Thu, May 14, 2009 at 6:44 PM, Carlos Proal wrote:
Check how many root rows do you have on the user table (select * from user
where user='root';), some ti
On Thu, May 14, 2009 at 6:44 PM, Carlos Proal wrote:
>
> Check how many root rows do you have on the user table (select * from user
> where user='root';), some times there are several rows with different grants
> and probably you are going through and invalid rule.
I checked and when I ran the co
Check how many root rows do you have on the user table (select * from
user where user='root';), some times there are several rows with
different grants and probably you are going through and invalid rule.
Carlos
On 5/14/2009 5:39 PM, Carlos Williams wrote:
On Thu, May 14, 2009 at 6:31 PM, C
On Thu, May 14, 2009 at 6:31 PM, Carlos Proal wrote:
>
> Hi Carlos
>
> Try this
>
> mysql> update user set password=password('letmein') where user='root';
>
>
> This way the password is saved encrypted, thats the way is compared when you
> try to log in.
Thanks for the reply! I followed both met
Hi Carlos
Try this
mysql> update user set password=password('letmein') where user='root';
This way the password is saved encrypted, thats the way is compared when
you try to log in.
Carlos
On 5/14/2009 5:28 PM, Carlos Williams wrote:
I noticed today that I strangely was unable to login
I noticed today that I strangely was unable to login to MySQL as root.
I just assumed I forgot the password and decided to reset my root
password:
1 - /etc/init.d/mysqld stop
2 - mysqld_safe --skip-grant-tables &
3 - mysql -u root
4 - mysql> use mysql;
mysql> mysql> update user set password='l
Store as CHAR(12), not VARCHAR because they are ALWAYS a fixed length. It
saves space and is faster to index/lookup.
If you're using IPv4 only
then stick with CHAR(12).
elseif you think you'll go to IPv6 then
if large dataset (> 1M rows say),
plan for it now as
I agree, and didn't mean to say that I disagreed. This is certainly one of the
top five principles to follow, imo. Too many times, while trouble-shooting,
I've run up on the rock of a binary (meaning: indecipherable) field.
What is the cost of including the binary representation (for indexing)
As I said in my post, this is a general principle for me. Nominal data
should have a data type of some sort of character. You will never run into
unexpected problems down the line.
On Thu, May 14, 2009 at 11:04 AM, Pete Wilson wrote:
>
>
> I'm new to MySQL so can't answer the OP's question,
I'm new to MySQL so can't answer the OP's question, but:
MAC addresses do not by design contain letters. Native MAC addresses are 48-bit
(6-byte) integers:
http://standards.ieee.org/getieee802/download/802-2001.pdf
The confusion arises because a MAC address is usually /represented/ as
hex
Definitely CHAR (or VARCHAR).
If the format of a MAC address changes at all, you could be in real
trouble. Also, if a MAC address can have a leading 0 (I don't know anything
about MAC addresses), then storing it as some sort of number could lose
that.
This is a general rule for me. A field migh
On Thu, 14 May 2009, Ilia KATZ wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi
It depends. You may convert the MAC address to a decimal integer and store
Not exactly. The allowed letters are A,B,C,D, E, F. Every 2 characters
(not including separators) can be treated as a hexadecimal number that
can be represented with one byte. 6 bytes in total.
for example: 00:1D:7D:48:08:8F
pair value
00
You might even want to plan for longer MAC addresses. I don't follow
developments in that area, but they had to go from IP4 to IP6 and they might
have to introduce longer MAC addresses.
It isn't hard to change a MySQL field definition, but your applications
would be more of a problem.
>-Origi
On Thursday 14 May 2009 09:53:58 am Fish Kungfu wrote:
> Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
> would say go with CHAR(12).
>
> On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
>
> Hi.
> Currently I have a table:
> 1. MAC address defined as BIGINT
> 2. MAC address
Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
would say go with CHAR(12).
On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi Scott
You may use the script below to reload replication if you can ensure that
the master db doesn't change during the dump operation. Otherwise you may
set a lock on the master manually.
Regards, Thomas
#!/bin/bash
#
# replicate-reload
#
# This is free software. There is no warranty a
31 matches
Mail list logo
