Hi Monty,
Michael Widenius wrote:
> Hi!
>
>> "Peter" == Peter Gulutzan writes:
>
> Peter> Hi all,
> Peter> On 01/15/2009 03:11 PM Peter Gulutzan wrote:
>
>>> For a TIME or DATETIME or TIMESTAMP literal, one can use
>>> '.' instead of ':' and one can skip leading fields. For example:
>>> IN
I wonder why with tre different MySQL administrator istances I have 3
different QueryCache Hitrate on the same database, in the same time :(
I'm trying with:
- MySQL administrator v.1.2.12 (Ubuntu 8.10): the query hitcache is
always at 100% (average 100)
- MySQL administrator v.1.2.5rc (De
I wonder why with tre different MySQL administrator istances I have 3
different QueryCache Hitrate on the same database, in the same time :(
I'm trying with:
- MySQL administrator v.1.2.12 (Ubuntu 8.10): the query hitcache is
always at 100% (average 100)
- MySQL administrator v.1.2.5rc (De
Michael Widenius wrote:
Hi!
"Peter" == Peter Gulutzan writes:
Peter> Hi all,
Peter> On 01/15/2009 03:11 PM Peter Gulutzan wrote:
For a TIME or DATETIME or TIMESTAMP literal, one can use
'.' instead of ':' and one can skip leading fields. For example:
INSERT INTO t (datetime_column) VALUE
Probably records were deleted in a transaction, which was later rolled back?
2009/1/25 Ariela Levy
>
> Hi there,
>
> I'm running an ecommerce site and have manually deleted customer records
> from mysql database however it seems these records still exist because my
> authentication routine for l
Hi there,
I'm running an ecommerce site and have manually deleted customer records from
mysql database however it seems these records still exist because my
authentication routine for login is finding a match for the primary key in the
customer table ( email).
Does anyone have an idea whethe
