Re: lost mysql root password

[anoop aryal <aaryal@foresightint.com>]

On Friday 03 March 2006 03:12 pm, Matt Price wrote:
> > do:
> >
> > select hex(User) from user where User LIKE 'root%';
> >
> >
> > that should give you the hex values of the characters that are there.
> >
> > > have all four.  I guess there must be some white space in the username
> > > somewhere.  Is there an easy way to identify the precise value of a
> > > mysql field (e.g. by dumping to a CSV file)? I'd like to try to figure
>
> +----------------------------------+
>
> | hex(User)                        |
>
> +----------------------------------+
>
> | 726F6F74                         |
> | 726F6F74202020202020202020202020 |
> | 726F6F74                         |
> | 726F6F74202020202020202020202020 |
>
> +----------------------------------+
> 4 rows in set (0.00 sec)
>
> thanks anoop!  I guess those 02's are spaces then...  Looks like most
> of the user lines from my old db are corrupted in this way as well.
> wierd.

i would check the encoding being used vs. the encoding that was used when it 
was initially created. it sounds like you were using a wide_char encoding 
(eg. UTF-8) before and somehow has now reverted back to latin-1 or some other 
single char encodings. i'm not an expert on encodings etc.. know just enough 
to be dangerous. but if this is database wide, (look at char/varchar/text 
fields and they should all display this behavior), this is encoding related. 
on a wide char encoding (say utf-8), the database reserves multiple bytes per 
char not knowing what char it will need to save there. when you tell mysql 
that it's not wide char, it will just show you what it has - including the 
previously reserved bytes. it's odd that it's using x20 to pad data tho.

or something like that.


> Thanks much for your help!
>
> matt

-- 


anoop
aaryal@foresightint.com