mysql can't start up

Hi I have installed mysql some software on aix5.2 . the edition is mysql-standard-4.0.21-ibm-aix5.2.0.0-powerpc but mysql can't run when I used the command "safe_mysqld start" the system told me "Starting mysqld daemon with databases from /usr/local/mysql/data STOPPING server from pid file /usr

Re: problems setting up the anonymous and root passwords

On Sep 20, 2004, at 00.06, FayeC SQL wrote: Hi, I have just finished installing MySQL, Apache and PHP on a Windows platform and have tested my Apache and PHP installations without problems. My issue now is that when I log in using just -u root I can get through but I just can't seem to be able to s

Re: problems setting up the anonymous and root passwords

Did you run mysql_install_db? Michael FayeC SQL wrote: Hi, I have just finished installing MySQL, Apache and PHP on a Windows platform and have tested my Apache and PHP installations without problems. My issue now is that when I log in us

problems setting up the anonymous and root passwords

Hi, I have just finished installing MySQL, Apache and PHP on a Windows platform and have tested my Apache and PHP installations without problems. My issue now is that when I log in using just -u root I can get through but I just can't seem to be able to set a password. It keeps giving me an error

Fw: Create index hange and crush replication

Dear Mysql:

RE: auto increment fields

Hi Mike: Instead off delete a record, i would put a status field to indicate that the record is deleted, and create a function that returns the key of the first record with the deleted status for reuse, and in case that there is no record to reuse, to create a new one and return that key. But you

Re: auto increment fields

On Sun, 19 Sep 2004 23:59:02 +0300, Mike <[EMAIL PROTECTED]> wrote: > hi. > I have a rather childish question on tables and auto increment fields. > Scenario: I have a table with an field. The > deal is that everything works fine (I'm talking about the auto > incrementation part) > until I choose

auto increment fields

hi. I have a rather childish question on tables and auto increment fields. Scenario: I have a table with an field. The deal is that everything works fine (I'm talking about the auto incrementation part) until I choose to delete a row. This creates a gap in the primary key field. And my question i

auto increment fields

hi. I have a rather childish question on tables and auto increment fields. Scenario: I have a table with an field. The deal is that everything works fine (I'm talking about the auto incrementation part) until I choose to delete a row. This creates a gap in the primary key field. And my question i

Re: Replication between 4.0.18 and 3.23.36 ??

Tim Wood wrote: Hi I have been running a master slave replication setup for the last few years on mysql versions 3.23.36 (which was bundled with redhat 7.1 back in the day). Anyway, I finally convinced our boss to purchase a new server and we've ended up installing mandrake 10 which comes complete

Re: Query takes terribly long

No, I'm quiet sure that isn't the case as I am testing the optimized version of my website on another database. Hm, I'll let you know if I find out what's causing it. If you have any more ideas, please inform me about them! Storing day, month and year in other columns seems a little overkilling

Re: Query takes terribly long

Hi, The query is still slow because MySQL can't use the index to search the right putdatetime. So unless you store in seperated columns day, month and year, so that you can query on those fields without a function, this will remain slow. Are you sure no other "long" queries are running on this tab

Re: Query takes terribly long

Hello, Indeed, when I use {put,front,putdatetime}, no filesort is used. But the query is still very slow. It takes about 2 seconds. And again, mysql prefers not to use your key, but I can force that of course. I did an ANALYZE TABLE but that didn't change things, it might have sped up the other

Re: Query takes terribly long

Hi, I would say for this one you need an index on (put, front, putdatetime) to get rid of the filesorting. Note that because you're transforming the putdatetime column with functions, MySQL will not be able to use index infos of putdatetime. So it will use put and front index information to find t

Re: Query takes terribly long

Hi, The only reason which could explain this is that statistics about the second query are perhaps not uptodate. Did you try to do an ANALYZE TABLE on it ? Regards, Jocelyn Fournier www.presence-pc.com - Original Message - From: "Dirk Schippers" <[EMAIL PROTECTED]> To: "Jocelyn Fourn

Re: Query question

On Sat, 18 Sep 2004 23:57:59 +0200, Schalk Neethling <[EMAIL PROTECTED]> wrote: > If I submit the following query: > > SELECT * FROM mi_verdicts_search WHERE doctype = 'Verdict' AND (state = > 'California: State Court' OR district = 'Circuit Court: Federal, Alaska' > OR appellate = 'US Supreme Cou

Re: Query takes terribly long

Hello, Sorry to bother you again, but now I have the following, bit more complicated query on the same table: SELECT id FROM story WHERE MONTH(putdatetime) = MONTH('2004-09-19') AND DAYOFMONTH(putdatetime) = DAYOFMONTH('2004-09-19') AND YEAR(putdatetime) < YEAR('2004-09-19') AND put=1 AND front=

Re: Query takes terribly long

Hello, Thanks for the hint! With RESET QUERY CACHE, I'm always sure that the cache is empty and with that, I've discovered that using the key as you said, with the datetime field included, is much!!! faster than the other key (no filesort is used). But, the strange thing is that with the index