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 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 have any affect. > > Cheers

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 wrote: > On 31/03/2010 16:52, Tompkins Neil wrote: > >> Hi >> >> I have the following

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 r

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

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 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 i

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 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, so you don't need to

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

ERS A_ID <--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 (t

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 colum

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

n a column 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 verti

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, INT01...INT

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 ap

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 |

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 |

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 | smal

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

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

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

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 lar

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,

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 numbe

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 t

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 vis

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 th

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 > a

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 for

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 examp

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: "112,249","al

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 on

Re: storing large integers properly

ne 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 on them. Besides, don't some ISBNs end in 'X'? -- MySQL General Mailing List For list archiv

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 proper

Re: storing large integers properly

t; Gesendet: Dienstag, 5. August 2003 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 tha

Re: storing large integers properly

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 digit numbers, the 0 is being ignor

Re: storing large integers properly

data > types 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

Re: storing large integers properly

hat start > with 0 are going 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

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 h

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 di

Re: Reshuffling unique integers

; To: "Mysql" <[EMAIL 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 > call

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

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'

48-bit integers, partial integer indexes ?

MySQL (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)

Re: ENUM -- integers or strings?

ary 4, 2002, at 03:07 PM, 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] | > Subje

Re: ENUM -- integers or strings?

y, 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, and the possible values are ("0", > "1", "2", "3"), does the num

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

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

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 co