Fulltext Match BOOLEAN MODE not searching integers

Hi I have the following fulltext search which appears to work fine for string phrases. However if I search like just 51 which is part of the string name like 51 Blue Widget in the table it doesn't return any results. However if I search like bl it returns the 51 Blue Widget result. My query is

Re: Fulltext Match BOOLEAN MODE not searching integers

On 31/03/2010 16:52, Tompkins Neil wrote: Hi I have the following fulltext search which appears to work fine for string phrases. However if I search like just 51 which is part of the string name like 51 Blue Widget in the table it doesn't return any results. However if I search like bl it

Re: Fulltext Match BOOLEAN MODE not searching integers

Hi Mark I did infact change the value of ft_min_word_len to 1. Rebuild the indexes using REPAIR table name. But it didn't appear to have any affect. Cheers Neil On Wed, Mar 31, 2010 at 5:29 PM, Mark Goodge m...@good-stuff.co.uk wrote: On 31/03/2010 16:52, Tompkins Neil wrote: Hi I have

Re: Fulltext Match BOOLEAN MODE not searching integers

Hi I found by using the REPAIR command it is now working. Thanks, Neil On Wed, Mar 31, 2010 at 5:38 PM, Tompkins Neil neil.tompk...@googlemail.com wrote: Hi Mark I did infact change the value of ft_min_word_len to 1. Rebuild the indexes using REPAIR table name. But it didn't appear to

Re: What should it be in MySql? In C, it's an array of integers.

On Thu, Sep 17, 2009 at 3:46 AM, John Meyer john.l.me...@gmail.com wrote: Alternatively, you can skip the A_ID and have a compound key of USER_ID and A_NUMBER on the ASSOC_NUMBERS table. I prefer the A_ID, though. Note that this would be marginally faster, because all your data is in the index,

Re: What should it be in MySql? In C, it's an array of integers.

Johan De Meersman wrote: On Thu, Sep 17, 2009 at 3:46 AM, John Meyer john.l.me...@gmail.com wrote: Alternatively, you can skip the A_ID and have a compound key of USER_ID and A_NUMBER on the ASSOC_NUMBERS table. I prefer the A_ID, though. Note that this would be marginally faster,

What should it be in MySql? In C, it's an array of integers.

Hi folks -- What would be the right approach in MySql 5.0? My table, USERS, has columns NAME and IP. Associated with each user is also a collection of from 0 to 50 INTs. What's a reasonable way to put these 50 INTs in the table without using 50 separate columns, INT01...INT50? Is BLOB an OK

Re: What should it be in MySql? In C, it's an array of integers.

Pete Wilson wrote: Hi folks -- What would be the right approach in MySql 5.0? My table, USERS, has columns NAME and IP. Associated with each user is also a collection of from 0 to 50 INTs. What's a reasonable way to put these 50 INTs in the table without using 50 separate columns,

Re: What should it be in MySql? In C, it's an array of integers.

as an XML doc where the application had to fetch all the submissions within the group and parse them in order to figure out who the submitters were. This was being done at the gateway page of that tool. It was a performance nightmare. An alternative might be to store the integers vertically

Re: What should it be in MySql? In C, it's an array of integers.

Pete wrote: Hi folks -- What would be the right approach in MySql 5.0? My table, USERS, has columns NAME and IP. Associated with each user is also a collection of from 0 to 50 INTs. What's a reasonable way to put these 50 INTs in the table without using 50 separate columns,

Re: What should it be in MySql? In C, it's an array of integers.

--primary key USER_ID -- foreign key linked to users A_NUMBER ---one of the integers that you would store Alternatively, you can skip the A_ID and have a compound key of USER_ID and A_NUMBER on the ASSOC_NUMBERS table. I prefer the A_ID, though. Another way I've read about (though I can't remember

integers fields and strings

I am having some issues with some integer fields and string input. The table setup is the following: | Field | Type| Null | Key | Default | Extra | | intfield1 | smallint(6) | YES | | 0| | | intfield2 | smallint(6) | YES | | NULL| | | intfield3 |

Re: integers fields and strings

On Fri, Mar 14, 2008 at 12:04 PM, Les Fletcher [EMAIL PROTECTED] wrote: | Field | Type| Null | Key | Default | Extra | | intfield1 | smallint(6) | YES | | 0| | | intfield2 | smallint(6) | YES | | NULL| | | intfield3 | smallint(6) | YES | |

Re: integers fields and strings

Thanks for the link. That helps a lot. Rob Wultsch wrote: On Fri, Mar 14, 2008 at 12:04 PM, Les Fletcher [EMAIL PROTECTED] wrote: | Field | Type| Null | Key | Default | Extra | | intfield1 | smallint(6) | YES | | 0| | | intfield2 | smallint(6) | YES | |

PHP 4.X with 64-Bit Integers From MySQL

I have a box where I'm forced to use PHP before 64-bit integers became standard ... If I run a MySQL query where one of the fields returned is 64-bit integer, how do I get this into PHP as a string? My recollection is that in the PHP result sets it auto types so that it is an integer, and 64

mysql and large integers

It looks like when mysql coerces character strings into integers, it turns them into signed int's. Obviously if the column is unsigned, this is a problem. Don't use quotes you say. Problem is that the perl DBI API seems to put quotes around everything. So when I grab a really really large integer

Re: mysql and large integers

At 16:34 -0800 12/3/04, Mark Maunder wrote: It looks like when mysql coerces character strings into integers, it turns them into signed int's. Obviously if the column is unsigned, this is a problem. Don't use quotes you say. Problem is that the perl DBI API seems to put quotes around everything

Re: mysql and large integers

Thanks very much Paul. My day has just improved. On Fri, 2004-12-03 at 16:53, Paul DuBois wrote: At 16:34 -0800 12/3/04, Mark Maunder wrote: It looks like when mysql coerces character strings into integers, it turns them into signed int's. Obviously if the column is unsigned

sorting strings as integers

Hi, I have a database column (VARCHAR) consisting of the following kind of data: 1 1.1 1.2.1.2 1.10.1 1.2 1.4.1 I need to sort this colum so that the result will be 1 1.1 1.2 1.2.1.2 1.4.1 1.10.1 I was hoping that just using ORDER BY [column] ASC would work, but alas, it only works for number

Re: sorting strings as integers

Ole Kasper Olsen wrote: Hi, I have a database column (VARCHAR) consisting of the following kind of data: 1 1.1 1.2.1.2 1.10.1 1.2 1.4.1 I need to sort this colum so that the result will be 1 1.1 1.2 1.2.1.2 1.4.1 1.10.1 I was hoping that just using ORDER BY [column] ASC would work, but alas,

integers

I created my first table with integer columns and am having trouble importing csv files with MySQL-Front. My decimal columns work fine, but not int. I had it set up like this: int 10 (length) NULL NULL The error message is kind of strange. It looks like every single value is incorrect, but it

Integers - How would you enter 112,249?

When I try to import my csv file in MySQL-Front, it appears to get hung up on every integer - or perhaps it's just every integer in the first integer field. When it cites an error, it only lists the numerals after the comma. For example, it says 249 for this sample from my csv file:

Re: Integers - How would you enter 112,249?

In the last episode (May 14), David Blomstrom said: When I try to import my csv file in MySQL-Front, it appears to get hung up on every integer - or perhaps it's just every integer in the first integer field. When it cites an error, it only lists the numerals after the comma. For example,

Re: Integers - How would you enter 112,249?

At 8:34 -0700 5/14/04, David Blomstrom wrote: When I try to import my csv file in MySQL-Front, it appears to get hung up on every integer - or perhaps it's just every integer in the first integer field. When it cites an error, it only lists the numerals after the comma. For example, it says 249

Re: Integers - How would you enter 112,249?

David Blomstrom [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] When I try to import my csv file in MySQL-Front, it appears to get hung up on every integer - or perhaps it's just every integer in the first integer field. When it cites an error, it only lists the numerals after the

Re: Integers - How would you enter 112,249?

--- Joshua Beall [EMAIL PROTECTED] wrote: AFAIK 112,249 is not an integer. It is a string. If you need to have the commas, you need to store it as a string. I haven't got to strings yet. The table I'm making is for display purposes, so I want visitors to be able to see 10,212, rather than

Re: Integers - How would you enter 112,249?

At 10:17 -0700 5/14/04, David Blomstrom wrote: --- Joshua Beall [EMAIL PROTECTED] wrote: AFAIK 112,249 is not an integer. It is a string. If you need to have the commas, you need to store it as a string. I haven't got to strings yet. The table I'm making is for display purposes, so I want

Re: Integers - How would you enter 112,249?

David Blomstrom wrote --- Joshua Beall [EMAIL PROTECTED] wrote: AFAIK 112,249 is not an integer. It is a string. If you need to have the commas, you need to store it as a string. I haven't got to strings yet. The table I'm making is for display purposes, so I want visitors to be able to see

RE: storing large integers properly

Eben. Yes, use a character based data type as the leading zero's are insignificant and will be removed. HTH Kev. -- From: Eben Goodman Sent: Tuesday, August 5, 2003 14:49 PM To: [EMAIL PROTECTED] Subject: storing large integers properly I am storing book

Re: storing large integers properly

codes, Social Security numbers, etc., are generally stored as strings, not integers, since they can have leading 0s and you're not going to do calculations on them. Besides, don't some ISBNs end in 'X'? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql

Re: storing large integers properly

15:49 Betreff: storing large integers properly I am storing book isbn numbers in a table. isbn numbers are 10 digit numbers and many start with 0. The data type of the field I am storing this info in is a bigint(16) unsigned. It appears that isbns that start with 0 are going in as 9

Re: storing large integers properly

ignoring leading 0s. I'm wondering how to address this? Should I change the field to a varchar or char data type? Yes. Phone numbers, zip codes, Social Security numbers, etc., are generally stored as strings, not integers, since they can have leading 0s and you're not going to do calculations

Re: storing large integers properly

How about BIGINT(10) ZEROFILL ? Eben Goodman wrote: I am storing book isbn numbers in a table. isbn numbers are 10 digit numbers and many start with 0. The data type of the field I am storing this info in is a bigint(16) unsigned. It appears that isbns that start with 0 are going in as 9

storing large integers properly

I am storing book isbn numbers in a table. isbn numbers are 10 digit numbers and many start with 0. The data type of the field I am storing this info in is a bigint(16) unsigned. It appears that isbns that start with 0 are going in as 9 digit numbers, the 0 is being ignored or stripped. I

Re: storing large integers properly

in as 9 digit numbers, the 0 is being ignored or stripped. I have experienced this before with integer data types ignoring leading 0s. I'm wondering how to address this? Should I change the field to a varchar or char data type? Integers are numeric values, they don't have leading zeroes

Reshuffling unique integers

I have a table in which the first column represents the order in which the data in the rows will appear in an HTML table on a Web page. The column is called ordr (to avoid conflict with the reserved keword order). This column is a primary key, but the values are not auto-incremented, they are

Re: Reshuffling unique integers

PROTECTED] Sent: Tuesday, March 04, 2003 11:28 PM Subject: Reshuffling unique integers I have a table in which the first column represents the order in which the data in the rows will appear in an HTML table on a Web page. The column is called ordr (to avoid conflict with the reserved keword order

Converting signed and unsigned integers

All, I have a table which includes IP addresses converted from dotted quads to signed integers using PHP's ip2long() function. To greatly simplify some of my code, I want to convert these signed integers to IP addresses on my MySQL server. The problem I'm up against is that PHP's ip2long uses

48-bit integers, partial integer indexes ?

(which is really annoying because application languages like Perl do not necessarily accept integers wider than 32 bits). Thank you Antoine. - Before posting, please check: http://www.mysql.com/manual.php (the manual) http

ENUM -- integers or strings?

A quick question -- If I have a table with an ENUM column, and the possible values are (0, 1, 2, 3), does the number qualify as an integer or a string? I am working in PHP4 and intend to compare this value as such: // dbaccess.access_level is ENUM(0, 1, 2, 3) column // $user_id has been

RE: ENUM -- integers or strings?

What happened when you experimented? What were your results? -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: ENUM -- integers or strings? A quick question -- If I have a table with an ENUM column

Re: ENUM -- integers or strings?

PROTECTED] Subject: ENUM -- integers or strings? A quick question -- If I have a table with an ENUM column, and the possible values are (0, 1, 2, 3), does the number qualify as an integer or a string? I am working in PHP4 and intend to compare this value as such: // dbaccess.access_level is ENUM

Re: ENUM -- integers or strings?

, Rick Emery wrote: | | What happened when you experimented? What were your results? | | -Original Message- | From: Erik Price [mailto:[EMAIL PROTECTED]] | Sent: Friday, January 04, 2002 2:03 PM | To: [EMAIL PROTECTED] | Subject: ENUM -- integers or strings? | | | A quick

Re: display size of integers

Hi. On Mon, Nov 26, 2001 at 02:45:26PM -0500, [EMAIL PROTECTED] wrote: I have a rhetorical question. I'm learning as much as I can about MySQL. There is one little detail that I don't *have* to know the answer to, but I'm curious about. Don't waste your time replying if you're busy.

display size of integers

I have a rhetorical question. I'm learning as much as I can about MySQL. There is one little detail that I don't *have* to know the answer to, but I'm curious about. Don't waste your time replying if you're busy. It appears that the display width is an option for certain types of numeric