Re: CLI can't read data from table

2010-04-14 Thread Dan Nelson
In the last episode (Apr 14), Mike Diehl said: > On Wednesday 14 April 2010 5:49:43 pm Jesper Wisborg Krogh wrote: > > Lines is a reserved keyword (e.g. like in "LINES TERMINATED BY"), so it > > must be quoted: > > > > test> use test; > > Database changed > > test> CREATE TABLE `lines` (id int unsi

Re: Make delete requests without impact on a database

2010-04-14 Thread Perrin Harkins
On Wed, Apr 14, 2010 at 10:22 AM, Dan Nelson wrote: > Switch to InnoDB :) Seconded. No need to complicate your life with MyISAM workarounds when InnoDB solves this problem already. - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http:/

Re: CLI can't read data from table

2010-04-14 Thread Mike Diehl
On Wednesday 14 April 2010 5:49:43 pm Jesper Wisborg Krogh wrote: > Lines is a reserved keyword (e.g. like in "LINES TERMINATED BY"), so it > must be quoted: > > test> use test; > Database changed > test> CREATE TABLE `lines` (id int unsigned NOT NULL PRIMARY KEY) > ENGINE=InnoDB; Query OK, 0 rows

Re: CLI can't read data from table

2010-04-14 Thread Jesper Wisborg Krogh
On Thu, 15 Apr 2010 09:31:04 Mike Diehl wrote: > I just created a new table called "lines." I can use Open Office to read > the records in it just fine. > > However, when I type this command at the cli, I get an error: > > > select * from lines; > ERROR 1064 (42000): You have an error in your SQL

CLI can't read data from table

2010-04-14 Thread Mike Diehl
Hi all. Now this one is strange. I just created a new table called "lines." I can use Open Office to read the records in it just fine. However, when I type this command at the cli, I get an error: select * from lines; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual

RE: Make delete requests without impact on a database

2010-04-14 Thread Daevid Vincent
> -Original Message- > From: Dan Nelson [mailto:dnel...@allantgroup.com] > Sent: Wednesday, April 14, 2010 7:23 AM > To: David Florella > Cc: mysql@lists.mysql.com > Subject: Re: Make delete requests without impact on a database > > In the last episode (Apr 14), David Florella said: > > I

Re: Make delete requests without impact on a database

2010-04-14 Thread Carsten Pedersen
mos skrev: At 01:20 PM 4/14/2010, Carsten Pedersen wrote: Been there, done that. It's a maintenance nightmare. Why is it a maintenance nightmare? I've been using this technique for a couple of years to store large amounts of data and it has been working just fine. In a previous reply, you

Re: Make delete requests without impact on a database

2010-04-14 Thread mos
At 01:20 PM 4/14/2010, Carsten Pedersen wrote: Been there, done that. It's a maintenance nightmare. Why is it a maintenance nightmare? I've been using this technique for a couple of years to store large amounts of data and it has been working just fine. I have each table representing one year

Re: numeric types

2010-04-14 Thread Carsten Pedersen
Check out the DECIMAL type. / Carsten Sebastien MORETTI skrev: Hello, I have a row which is defined as double unsigned (MySQL 5.0.26-Max, OpenSuse). Values in this row can go from a single digit, like 1, to values like 0.0006872207 or 1.2513e-18. I want to store exact numbers. But I wo

Re: Make delete requests without impact on a database

2010-04-14 Thread Carsten Pedersen
Been there, done that. It's a maintenance nightmare. Another idea: Have a separate "deleted" table with the IDs of the rows that you consider deleted. Re-write your queries to do a left-join-not-in-the-other-table agains the "delete" table. Then, either wait for a maintenance window to delete

numeric types

2010-04-14 Thread Sebastien MORETTI
Hello, I have a row which is defined as double unsigned (MySQL 5.0.26-Max, OpenSuse). Values in this row can go from a single digit, like 1, to values like 0.0006872207 or 1.2513e-18. I want to store exact numbers. But I would like also this: 1 stored as 1.0 0.098

Re: Make delete requests without impact on a database

2010-04-14 Thread mos
It looks like you only want to keep the current data, perhaps the current day's worth, and delete the old data. I would store the data in separate MySIAM tables, each table would represent a date, like D20100413 and D20100414. Your program will decide which table to insert the data into by cre

Re: Make delete requests without impact on a database

2010-04-14 Thread Dan Nelson
In the last episode (Apr 14), David Florella said: > I am using MySQL version 4.1.12-log. All the databases on it are using > MyISAM database engine. > > Every day, I delete almost 9 rows on a table of 3 153 916 rows. > > To delete the rows, I use a request like this : "DELETE QUICK FROM [tab

Make delete requests without impact on a database

2010-04-14 Thread David Florella
Hi, I am using MySQL version 4.1.12-log. All the databases on it are using MyISAM database engine. Every day, I delete almost 9 rows on a table of 3 153 916 rows. To delete the rows, I use a request like this : "DELETE QUICK FROM [table] WHERE [column] < '2010-04-13 00:00:00' LIM

Re: Recommended swap partition size

2010-04-14 Thread Glyn Astill
--- On Wed, 14/4/10, Dan Nelson wrote: > Hammerman said: > > My organization has a dedicated MySQL server. The > system has 32Gb of > > memory, and is running CentOS 5.3.  The default > engine will be InnoDB. > > Does anyone know how much space should be dedicated to > swap? > > I say zero swap

Re: Recommended swap partition size

2010-04-14 Thread Johan De Meersman
Correct, but when something *does* go amiss, some swap may give you the time you need to fix things before you really go down :-) So, yeah, a gig or two should be fine. There's also no real need for an actual swap partition, these days - just use a swap file. Performance is only marginally less th

Re: Fwd: Mixing Latin and UTF

2010-04-14 Thread walter harms
Huib schrieb: > > Hello, > > I hope that this is the right list. > > I have a database that has been running for years in latin1 but a > software update changed it in to utf8 that would be no big deal if we > know it right away so we could change the database. > > The big problem is that the