Re: Why MySQL-server-5.5.37 install fail?
Am 04.05.2014 08:29, schrieb EdwardKing: I'm newbie to mysql and I want to install mysql under Centos 5.8 using MySQL-server-5.5.37-1.linux2.6.i386.rpm, I use following command to intall mysql #[root@master software]# rpm -ivh MySQL-server-5.5.37-1.linux2.6.i386.rpm Preparing...### [100%] 1:MySQL-server ### [100%] [root@master bin]# pwd /usr/bin [root@master bin]# /usr/bin/mysqladmin -u root password '123456' bash: mysqladmin: command not found because you are only installing the server and not the clients packages RTFM or just use your distributions packages which would have pulled mysql by dependencies because the server makes little sense without the tools for a basic setup [root@hosting:~]$ rpm -q --file /usr/bin/mysqladmin mariadb-5.5.35-3.el7.x86_64 [root@hosting:~]$ rpm -q --file /usr/libexec/mysqld mariadb-server-5.5.35-3.el7.x86_64 signature.asc Description: OpenPGP digital signature
Re: Why MySQL-server-5.5.37 install fail?
Hello, mysqladmin and mysql command-line client is included in MySQL-client package. mysql_secure_installation is included in MySQL-server but it's a perl script which calls mysql command-line client internally. Thus, you should install MySQL-client-*.rpm and try again. Regards, 2014-05-04 15:29 GMT+09:00 EdwardKing zhan...@neusoft.com: I'm newbie to mysql and I want to install mysql under Centos 5.8 using MySQL-server-5.5.37-1.linux2.6.i386.rpm, I use following command to intall mysql #[root@master software]# rpm -ivh MySQL-server-5.5.37-1.linux2.6.i386.rpm Preparing...### [100%] 1:MySQL-server ### [100%] PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h master password 'new-password' Alternatively you can run: /usr/bin/mysql_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. Please report any problems at http://bugs.mysql.com/ Then I use following command: [root@master bin]# pwd /usr/bin [root@master bin]# /usr/bin/mysqladmin -u root password '123456' bash: mysqladmin: command not found [root@master bin]# ls mysqladmin ls: mysqladmin: No such file or directory [root@master bin]# mysql_secure_installation Can't find a 'mysql' client in PATH or ./bin How to install mysql and start mysql? Why are the commands of mysqladmin and mysql_secure_installation fail? I am puzzled with it for many days, I still can't find a solution. Anyone could help me? Thanks. Thanks. --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---
Re: why mysql choose a bad query
2010/11/4 Changying Li lchangy...@gmail.com: PRIMARY KEY (`threadid`), KEY `dateline` (`dateline`), KEY `forumid_2` (`forumid`,`thread_type_id`,`visible`,`sticky`,`dateline`), KEY `forumid` (`forumid`,`visible`,`sticky`,`dateline`) ) ENGINE=InnoDB AUTO_INCREMENT=660 DEFAULT CHARSET=utf8; mysql explain SELECT * FROM `abc` WHERE `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G possible_keys: forumid_2,forumid key: forumid_2 Extra: Using where; Using filesort why it choose forumid_2, not forumid ? 5.0 docs online say: With EXPLAIN SELECT ... ORDER BY, you can check whether MySQL can use indexes to resolve the query. It cannot if you see Using filesort in the Extra column. See Section 7.2.1, “Optimizing Queries with EXPLAIN”. Your query is using filesort, so it cannot according to the above statement. The docs also say in section 7.3.1.11 that it might not use an index if: The key used to fetch the rows is not the same as the one used in the ORDER BY... I'm curious, if you change the SELECT to a few named fields instead of *, does it affect the key choice? If you only select on fields in the key (i.e. a covering index) does it still choose what you consider to be the wrong key? -- Regards... Todd I seek the truth...it is only persistence in self-delusion and ignorance that does harm. -- Marcus Aurealius -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: why mysql choose a bad query
yes, I tried : mysql explain SELECT forumid,visible,sticky,dateline FROM `abc` WHERE `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G *** 1. row *** id: 1 select_type: SIMPLE table: abc type: ref possible_keys: forumid_2,forumid key: forumid key_len: 8 ref: const,const,const rows: 24 Extra: Using where; Using index 1 row in set (0.00 sec) and tried : mysql explain select threadid,thread_type_id,forumid,title,lastpost,open,replycount,postusername,postuserid,lastpostid,lastposter,lastpostuserid,dateline,views,visible,sticky,goodnees,votenum,votetotal,attach,hiddencount,deletedcount,pid from abc where `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G *** 1. row *** id: 1 select_type: SIMPLE table: abc type: ref possible_keys: forumid_2,forumid key: forumid_2 key_len: 3 ref: const rows: 24 Extra: Using where; Using filesort 1 row in set (0.00 sec) but why ? Must I use it by force index ? Todd Lyons tly...@ivenue.com writes: 2010/11/4 Changying Li lchangy...@gmail.com: PRIMARY KEY (`threadid`), KEY `dateline` (`dateline`), KEY `forumid_2` (`forumid`,`thread_type_id`,`visible`,`sticky`,`dateline`), KEY `forumid` (`forumid`,`visible`,`sticky`,`dateline`) ) ENGINE=InnoDB AUTO_INCREMENT=660 DEFAULT CHARSET=utf8; mysql explain SELECT * FROM `abc` WHERE `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G possible_keys: forumid_2,forumid key: forumid_2 Extra: Using where; Using filesort why it choose forumid_2, not forumid ? 5.0 docs online say: With EXPLAIN SELECT ... ORDER BY, you can check whether MySQL can use indexes to resolve the query. It cannot if you see Using filesort in the Extra column. See Section 7.2.1, “Optimizing Queries with EXPLAIN”. Your query is using filesort, so it cannot according to the above statement. The docs also say in section 7.3.1.11 that it might not use an index if: The key used to fetch the rows is not the same as the one used in the ORDER BY... I'm curious, if you change the SELECT to a few named fields instead of *, does it affect the key choice? If you only select on fields in the key (i.e. a covering index) does it still choose what you consider to be the wrong key? -- Regards... Todd I seek the truth...it is only persistence in self-delusion and ignorance that does harm. -- Marcus Aurealius -- Thanks Regards Changying Li -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: why mysql choose a bad query
On Fri, 2010-11-05 at 15:46 +0800, Changying Li wrote: yes, I tried : mysql explain SELECT forumid,visible,sticky,dateline FROM `abc` WHERE `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G *** 1. row *** id: 1 select_type: SIMPLE table: abc type: ref possible_keys: forumid_2,forumid key: forumid key_len: 8 ref: const,const,const rows: 24 Extra: Using where; Using index 1 row in set (0.00 sec) and tried : mysql explain select threadid,thread_type_id,forumid,title,lastpost,open,replycount,postusername,postuserid,lastpostid,lastposter,lastpostuserid,dateline,views,visible,sticky,goodnees,votenum,votetotal,attach,hiddencount,deletedcount,pid from abc where `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G *** 1. row *** id: 1 select_type: SIMPLE table: abc type: ref possible_keys: forumid_2,forumid key: forumid_2 key_len: 3 ref: const rows: 24 Extra: Using where; Using filesort 1 row in set (0.00 sec) but why ? Must I use it by force index ? Todd Lyons tly...@ivenue.com writes: 2010/11/4 Changying Li lchangy...@gmail.com: PRIMARY KEY (`threadid`), KEY `dateline` (`dateline`), KEY `forumid_2` (`forumid`,`thread_type_id`,`visible`,`sticky`,`dateline`), KEY `forumid` (`forumid`,`visible`,`sticky`,`dateline`) ) ENGINE=InnoDB AUTO_INCREMENT=660 DEFAULT CHARSET=utf8; mysql explain SELECT * FROM `abc` WHERE `forumid` = 25 AND `visible` = 1 AND `sticky` = 0 order by dateline \G possible_keys: forumid_2,forumid key: forumid_2 Extra: Using where; Using filesort why it choose forumid_2, not forumid ? 5.0 docs online say: With EXPLAIN SELECT ... ORDER BY, you can check whether MySQL can use indexes to resolve the query. It cannot if you see Using filesort in the Extra column. See Section 7.2.1, “Optimizing Queries with EXPLAIN”. Your query is using filesort, so it cannot according to the above statement. The docs also say in section 7.3.1.11 that it might not use an index if: The key used to fetch the rows is not the same as the one used in the ORDER BY... I'm curious, if you change the SELECT to a few named fields instead of *, does it affect the key choice? If you only select on fields in the key (i.e. a covering index) does it still choose what you consider to be the wrong key? -- Regards... Todd I seek the truth...it is only persistence in self-delusion and ignorance that does harm. -- Marcus Aurealius -- Thanks Regards Changying Li what if you added the dateline into the where clause?i understand that the indexs are used left to right, but could it just be the order by is the issue? I dunno honestly, but it does apear that forumid_2 is a better choice based on the key_len and rows that the explain shows... Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Why MySQL doesn't cache queries that populate temp tables?
Hello. As said at: http://dev.mysql.com/doc/mysql/en/query-cache-how.html A query will not be cached, if it uses TEMPORARY tables. Homam S.A. [EMAIL PROTECTED] wrote: Why MySQL insists on ignoring the query cache whenever I use the same query repeatedly to populate a temp table? So I have: create temporary table MyTable select SQL_CACHE * from SomeTable WHERE (A bunch of criteria) limit 1000; SomeTable is a read-only table. If I issue the query without the temp table population, it gets cached fine. It's just when I use the temp table MySQL stops caching. Is there a way to force MySQL to repopulate the temp table from the cache? Thanks! __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET ___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is very slow in dropping indexes?
All, slow index DROP and CREATE is a top complaint among MySQL users. Jan and Jani are now working to fix this. I guess in 2006 this problem has been removed. Best regards, Heikki Tuuri Innobase Oy Foreign keys, transactions, and row level locking for MySQL InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables http://www.innodb.com/order.php - Original Message - From: Martijn Tonies [EMAIL PROTECTED] Newsgroups: mailing.database.myodbc Sent: Friday, January 28, 2005 10:05 PM Subject: Re: Why MySQL is very slow in dropping indexes? This extreme slowness in dropping a simple index in MySQL defeats the whole strategy of dropping indexes on some tables before a huge insert operation. See http://dev.mysql.com/doc/mysql/en/alter-table.html , especially these bits: Note that if you use any other option to ALTER TABLE than RENAME, MySQL always creates a temporary table, even if the data wouldn't strictly need to be copied (such as when you change the name of a column). We plan to fix this in the future, but because ALTER TABLE is not a statement that is normally used frequently, this isn't high on our TODO list. As of MySQL 4.0, this feature can be activated explicitly. ALTER TABLE ... DISABLE KEYS tells MySQL to stop updating non-unique indexes for a MyISAM table. ALTER TABLE ... ENABLE KEYS then should be used to re-create missing indexes. MySQL does this with a special algorithm that is much faster than inserting keys one by one, so disabling keys before performing bulk insert operations should give a considerable speedup. You want to DISABLE, not DROP, the keys. Which, btw, is very misleading -- non-unique indices are NOT keys. They're indices. I would only consider unique constraints and primary key constraints actual keys. :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is very slow in dropping indexes?
Homam S.A. [EMAIL PROTECTED] wrote on 01/28/2005 02:27:51 PM: Dropping an index on a MyISAM table should be instantaneous. It should only take as long as deleting the idx file from the file system. But it's taking almost as long as creating the index itself! Here's my queries and time they took: /*[10:58:17 AM][367172 ms]*/ alter table MyTable add index (MyIndex) /*[11:20:21 AM][183891 ms]*/ alter table MyTable drop index MyIndex In MS SQL server, if the index isn't clustered and there are no other indexes in the table, dropping the index is instantaneous. This extreme slowness in dropping a simple index in MySQL defeats the whole strategy of dropping indexes on some tables before a huge insert operation. Why doesn't it just delete the index file and clear whatever cached buffers it has of it? You neglected to mention which version of MySQL you are running. This behavior may have been fixed in newer versions as yours is not the first post I can remember seeing on this general topic. Shawn Green Database Administrator Unimin Corporation - Spruce Pine
Re: Why MySQL is very slow in dropping indexes?
Homam S.A. wrote: This extreme slowness in dropping a simple index in MySQL defeats the whole strategy of dropping indexes on some tables before a huge insert operation. See http://dev.mysql.com/doc/mysql/en/alter-table.html , especially these bits: Note that if you use any other option to ALTER TABLE than RENAME, MySQL always creates a temporary table, even if the data wouldn't strictly need to be copied (such as when you change the name of a column). We plan to fix this in the future, but because ALTER TABLE is not a statement that is normally used frequently, this isn't high on our TODO list. As of MySQL 4.0, this feature can be activated explicitly. ALTER TABLE ... DISABLE KEYS tells MySQL to stop updating non-unique indexes for a MyISAM table. ALTER TABLE ... ENABLE KEYS then should be used to re-create missing indexes. MySQL does this with a special algorithm that is much faster than inserting keys one by one, so disabling keys before performing bulk insert operations should give a considerable speedup. You want to DISABLE, not DROP, the keys. -- Keith Ivey [EMAIL PROTECTED] Smokefree DC http://www.smokefreedc.org Washington, DC -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is very slow in dropping indexes?
Homam S.A. wrote: Dropping an index on a MyISAM table should be instantaneous. It should only take as long as deleting the idx file from the file system. But it's taking almost as long as creating the index itself! Here's my queries and time they took: /*[10:58:17 AM][367172 ms]*/ alter table MyTable add index (MyIndex) /*[11:20:21 AM][183891 ms]*/ alter table MyTable drop index MyIndex In MySQL, most ALTER TABLE operations involve a full reconstruction of the table, so dropping a key often takes almost as long as adding one. For a long time, optimizing them has not been a priority. Also note that in MyISAM all keys are stored in one MYI file. So dropping a key is not as easy as just deleting a file. -- Sasha Pachev AskSasha Linux Consulting http://www.asksasha.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is very slow in dropping indexes?
This extreme slowness in dropping a simple index in MySQL defeats the whole strategy of dropping indexes on some tables before a huge insert operation. See http://dev.mysql.com/doc/mysql/en/alter-table.html , especially these bits: Note that if you use any other option to ALTER TABLE than RENAME, MySQL always creates a temporary table, even if the data wouldn't strictly need to be copied (such as when you change the name of a column). We plan to fix this in the future, but because ALTER TABLE is not a statement that is normally used frequently, this isn't high on our TODO list. As of MySQL 4.0, this feature can be activated explicitly. ALTER TABLE ... DISABLE KEYS tells MySQL to stop updating non-unique indexes for a MyISAM table. ALTER TABLE ... ENABLE KEYS then should be used to re-create missing indexes. MySQL does this with a special algorithm that is much faster than inserting keys one by one, so disabling keys before performing bulk insert operations should give a considerable speedup. You want to DISABLE, not DROP, the keys. Which, btw, is very misleading -- non-unique indices are NOT keys. They're indices. I would only consider unique constraints and primary key constraints actual keys. :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is used instead of MaxDB?
The answers are wide and varied: * History - MySQL has been an open source product for longer * Flexibility - MySQL's different table types are ideal for some situations * Performance - MySQL is the fastest database on the planet for most tasks * Support - There are massive amounts of software out there that will interface with MySQL [EMAIL PROTECTED] wrote: Hi Friends, I am working on a pilot project that will introduce open source databases in my organisation. In my search I have found that MySQL and MaxDB both are open source databases, but MaxDB is being used very less in comparison to MySQL. If I link this with the fact that MaxDB provides many advanced features that MySQL dowsn't provide, first question that hits my mind is why is it so? Why MySQL is used more in comparison to MaxDB I am unable to find any genuine reason behind this, hope you can help me out Thanks Regards... Pratik Ajmera Tata Consultancy Services Raheja Green, Kulupwadi Road, Borivali (East) Mumbai - 400 066,Maharashtra India Ph:- +91-22-56688712 Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Why MySQL is used instead of MaxDB?
Chris Nolan wrote: The answers are wide and varied: * History - MySQL has been an open source product for longer * Flexibility - MySQL's different table types are ideal for some situations * Performance - MySQL is the fastest database on the planet for most tasks * Support - There are massive amounts of software out there that will interface with MySQL --8 Just to add a few more thingies: Even though MaxDB has better looking admin tools (even the documentation is visually more appealing) MySQL is by a _BIG_ far easier to manage, learn and use (even easier to install!). I have been using both data bases for a few years now, I belong to both lists, the maxdb and the mysql list, i generally feel more confortable using mysql than max db, even the syntax used to admin the db seems to be easier to learn and use that the one that comes with dbcli(maxdb command line client). You can embed mysql server, you cannot embed maxdb is another nice thing. You can get mysql for free in almost every isp and webhosting on planet earth, maybe even in outter space, we'll see... =) I guess the average is about 1000 persons that knows about mysql against 1 that knows about maxdb You can even find more books on mysql. On the other side, maxdb is a _VERY_ feature rich data base, it has triggers, views, and every thing that you might expect from any other comercial grade db. A lack of this things in MySQL does not mean that mysql is a rather inferior choice, most of this feature can be replaced or simulated with a little tweaking and a good knoledge of the sql and mysql api. In the long run, i would like mysql to provide tools comparable to the ones provided by maxdb, things like a good gui to REALLY manage the db (i mean a tool that let me manipulate the my.cnf, just as an example) and implementing long awaited features like views and triggers (i know they are planned for 5.1 and above) (I WISH) i could get a nice mix of features of the best of maxdb and mysql, called it MEGA DB =) CONCLUSION: Download both, try both, subscribe to both list, evaluate them, there are certainly jobs, that both databases can perform equally, there are task that are better suited for one or the other. It's up to you. Anyway, we are here to help! =) Best Regards! -- |...| | _ _|Victor Medina M | |\ \ \| | _ \ / \ |Linux - Java - MySQL | | \ \ \ _| | |_) / _ \ |Dpto. Sistemas - Ferreteria EPA | | / / / |___| __/ ___ \ |[EMAIL PROTECTED] | |/_/_/|_|_| /_/ \_\|Tel: +58-241-8507325 - ext. 325 | ||Cel: +58-412-8859934 | ||geek by nature - linux by choice | |...| -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Why MySQL GUI download don't work?
Are you trying to use a download manager?. If so .. it didnt work for me. Disable it, and it will work. vicente -Mensaje original- De: Alex Shi [mailto:[EMAIL PROTECTED]] Enviado el: miércoles, 12 de diciembre de 2001 23:46 Para: [EMAIL PROTECTED] Asunto: Why MySQL GUI download don't work? I tried to download MySQL GUI from these links: http://www.mysql.com/Downloads/mysqlgui/mysqlgui-win32-static-1.7.5-2.zip and http://www.mysql.com/Downloads/mysqlgui/mysqlgui-linux-static-1.7.5-1.tar.gz But all these don't work. Alex - Original Message - From: Matthew Darcy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 9:22 AM Subject: RE: I must be mental but. I compiled without problem mysql on Redhat linux 7.1 I have just started the sever using nohup /usr/local/mysql/libexec/mysqld This started fine without problem. as I am used to using Oracle and new to mysql I decided to do an mysql_install_db which prompted me saying remember to change password using mysqladmin -p password `password` I did this and it asked me for a password ?? what is the password and how do I change it. This command to me suggests that -p password enters the password password and the `password` is the new password ??? can someone explain ?? Thanks, Matt. - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL GUI download don't work?
Alex Shi writes: I tried to download MySQL GUI from these links: http://www.mysql.com/Downloads/mysqlgui/mysqlgui-win32-static-1.7.5-2.zip and http://www.mysql.com/Downloads/mysqlgui/mysqlgui-linux-static-1.7.5-1.tar.gz But all these don't work. Alex Hi! Please try another mirror, because download worked for me. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL db will only allow 127 records imported?
Howard Picken [EMAIL PROTECTED] wrote: I'm trying to import a csv file into a db. all text fields are enclosed and all fields are , delimited. the file is 900 records long. The error I'm getting is.. ERROR 1062 at line 1: Duplicate entry '127' for key 1 Your ID field is type 'TINYINT' which can contain a max value of 127. Numbers larger than that are saved to the DB as 127 so it's choking b/c it's causing duplicate values for a key field. Change the field type to INT or something appropriate for your dataset. Make it UNSIGNED if you don't expect negative numbers in the ID field. SQL is your friend (added to please the filter). -- Steve Werby President, Befriend Internet Services LLC http://www.befriend.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Why MySQL db will only allow 127 records imported?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 25 April 2001 2:31 PM To: Howard Picken Subject: Why MySQL db will only allow 127 records imported? Your message cannot be posted because it appears to be either spam or simply off topic to our filter. To bypass the filter you must include one of the following words in your message: database,sql,query If you just reply to this message, and include the entire text of it in the reply, your reply will go through. However, you should first review the text of the message to make sure it has something to do with MySQL. You have written the following: I'm trying to import a csv file into a db. all text fields are enclosed and all fields are , delimited. the file is 900 records long. The error I'm getting is.. ERROR 1062 at line 1: Duplicate entry '127' for key 1 I'm importing an id field (incrementing from 1-900) which is the main index (I've tried importing without it). If I delete the first 200 lines from the import file. It won't import anything and I get the same error. If I remove all data from the table then try again I get the same problem. id is set to tinyint(5) I'm stumped... anyone have any ideas? Thanks Howard - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL db will only allow 127 records imported?
Tinyint will only go up to 127 when it is signed. Try INT. Also, please read the Docs section about data types and their sizes. It will save you more embarassing questions like these. :) j- k- On Tuesday 24 April 2001 20:39, Howard Picken wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 25 April 2001 2:31 PM To: Howard Picken Subject: Why MySQL db will only allow 127 records imported? Your message cannot be posted because it appears to be either spam or simply off topic to our filter. To bypass the filter you must include one of the following words in your message: database,sql,query If you just reply to this message, and include the entire text of it in the reply, your reply will go through. However, you should first review the text of the message to make sure it has something to do with MySQL. You have written the following: I'm trying to import a csv file into a db. all text fields are enclosed and all fields are , delimited. the file is 900 records long. The error I'm getting is.. ERROR 1062 at line 1: Duplicate entry '127' for key 1 I'm importing an id field (incrementing from 1-900) which is the main index (I've tried importing without it). If I delete the first 200 lines from the import file. It won't import anything and I get the same error. If I remove all data from the table then try again I get the same problem. id is set to tinyint(5) I'm stumped... anyone have any ideas? Thanks Howard - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php -- Joshua Kugler Associated Students of the University of Alaska Fairbanks Information Services Director [EMAIL PROTECTED] 907-474-7601 - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL?
On Friday 02 March 2001 18:22, Boulat Khakimov wrote: Hi guys, I'm wondering why you prefered mySQL overe Postgres , they are both open source, and accorting to many people Postgres is more powerful and stable than mySQL. Trivial installation and update on my Linux Redhat box thanks to the provided rpms. Fast, user friendly. Great working replication feature. A most user friendly an efficient mailling list. Most of all, great support. Those guys are incredible! You usually get an answer or even a fix in less than 1 hour! I've been using mySQL for awhile myself, but recently, I've been extremely frustrated by mySQLs bugginess ... the BDB transaction support for example is extremely unstable. I do not think it has been released as stable at this time. I have had no problems with MyISAM tables. -- Jean-Luc Fontaine - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL?
Boulat Khakimov wrote: Hi guys, I'm wondering why you prefered mySQL overe Postgres , they are both open source, and accorting to many people Postgres is more powerful and stable than mySQL. I've been using mySQL for awhile myself, but recently, I've been extremely frustrated by mySQLs bugginess ... the BDB transaction support for example is extremely unstable. Regards, Boulat Then stick with the Myisam or isam tables. The BDB is the current work-in-progress. The MySQL team will tell us when the BDB has been declared stable. I chose MySQL for our products because I could NOT get postgres to run on SCO Openserver, even though it was supposed to be supported. I tried for 2 months to get help on the postgress mailing list. Nobody offered ANY help. I could not afford to base our future on a product that had ZERO support. MySQL has better support than ANY commercial product I have ever used. Now you know. - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL?
I'm wondering why you prefered mySQL overe Postgres , they are both open source, and accorting to many people Postgres is more powerful and stable than mySQL. Hmm... It's free, robust, damn fast, small footprint, lots of free add on software available, it's free. The other thing is you will never want for tech support. This mailing list alone is some of the best damn tech support around - if I ever had to make a telephone tech support call it would probably be because the end of the world was coming soon... -- === "If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows." -- Sun Microsystems CEO, Scott McNealy __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Why MySQL?
Yes MySQL has excellent support :) Thats why I use MySQL and ASTA MySQL Server. Both of these are excellent produtcs. Cheers Mike -Original Message- FROM: [EMAIL PROTECTED] TO: [EMAIL PROTECTED] DATE: Fri 3/2/01 11:08 SUBJECT: Re: Why MySQL? I'm wondering why you prefered mySQL overe Postgres , they are both open source, and accorting to many people Postgres is more powerful and stable than mySQL. Hmm... It's free, robust, damn fast, small footprint, lots of free add on software available, it's free. The other thing is you will never want for tech support. This mailing list alone is some of the best damn tech support around - if I ever had to make a telephone tech support call it would probably be because the end of the world was coming soon... -- === "If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows." -- Sun Microsystems CEO, Scott McNealy __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Why MySQL?
On Fri, 2 Mar 2001, Evan James Dembskey wrote: I chose MySQL for our products because I could NOT get postgres to run on SCO Openserver, even though it was supposed to be supported. I tried for 2 months to get help on the postgress mailing list. Nobody offered ANY help. Funny, I had the same experience. The only reason I am no learning to use MySQL is because PostgresQL would not install on either my Linux box or my DEC box. The postgres list was not helpful. My current (personal) view on the debate is that PG is more advanced featurewise and they claim to be as fast. It's also much less user/admin-friendly and lacks (last I could tell) an important feature I've come to love (ALTER TABLE CHANGE column). However, mySQL is very fast. It's got virtually all of the features I need (row-level locking and transactions are what I'm waiting for to become stable). I've seen some stability problems but most were under Solaris. I look forward to it maturing and growing out of the "small to medium" range RDBMs that it's usually tagged as due to the (stable) lack of the two features I mentioned. By the way, found the -1 table handler problem. *sigh* Disk was at 100% usage on that partition. Got so used to scripts keeping track of disk usage I forgot to even consider that a possibility. Perhaps mySQL could so some testing to find the instances where it would get an error writing to the disk or temp file and indicate an error as such? I mean, you're going to get an error code back from your system (f)write call that indicates what the problem is... -- Nathan Clemons [EMAIL PROTECTED] 978-635-5300 ext 123 Linux Systems Administrator IRC: etrnl ICQ: 2810688 AIM: StormeRidr O | S | D | N,50 Nagog Park,Acton,MA01720 http://www.osdn.com/ Open Source Development Network Nextel: 978-423-0165 [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: why mysql eat my memory over 1G?
olivefan wrote: why mysql eat my memory over 1G?Please help me!Thank you!!! server1:DELL6300,4cpu,4G memory.solaris5.7 for X86 . mysql start command:nohup /usr/local/bin/safe_mysqld -O key_buffer=128M -O table_cache=512 -O sort_buffer=128M -O record_buffer=128M -O max_connections=999 -O wait_timeout=5000 use "top" show: last pid: 26041; load averages: 6.89, 9.39, 10.01 13:27:36 64 processes: 59 sleeping, 2 running, 3 on cpu CPU states: 0.8% idle, 68.1% user, 31.1% kernel, 0.0% iowait, 0.0% swap Memory: 4032M real, 557M free, 1787M swap in use, 3602M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 2838 root 147 200 1432M 1317M cpu1 62.1H 53.15% mysqld 3057 publish1 52 18M 12M sleep 67:32 2.08% perl 23734 publish1 220 17M 14M run 0:32 5.10% httpd 16703 publish1 580 17M 11M sleep 0:38 0.00% httpd server2:SunUltra-4,1cpu,1G memory,solaris5.7. mysql start command:nohup /usr/local/bin/safe_mysqld -O key_buffer=128M -O table_cache=512 -O sort_buffer=128M -O record_buffer=128M -O max_connections=999 -O wait_timeout=5000 use "top" show: load averages: 0.98, 1.09, 1.17 13:32:41 159 processes: 157 sleeping, 1 running, 1 on cpu CPU states: 0.0% idle, 57.3% user, 42.7% kernel, 0.0% iowait, 0.0% swap Memory: 1024M real, 16M free, 870M swap in use, 894M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 332 root 9 200 779M 400M run80.6H 89.60% mysqld 370 root 1 590 18M 13M sleep 0:15 0.00% Xsun 392 root 1 590 7136K 1248K sleep 0:09 0.00% dtgreet __ Olivefan: Looks like the Intel box is a little i/o starved. The Sun seems to be getting along fine, but, still a pretty high load. Not sure why the memory usage discrepancy, but, a mysqladmin extended might be more helpful. I'm assuming you're running the solaris on the Dell for filesystem size reasons. Must be a pretty big and busy dbase. That load's gonna kill the machine over time. What's the temperature on that thing? Van -- = Linux rocks!!! http://www.dedserius.com = - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
