"I've run up on the rock of a binary (meaning: indecipherable) field."
SELECT hex(some_binary_field) FROM table;
Solved.
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of
A MAC address is just a number, it doesn't contain letters unless you're doing
something silly like storing the HEX representation of it. Do not use CHAR!
This does DOUBLE for all of you storing IP addresses!
Since a MAC address is going to be between 48 and 64 bits, then
e an IP like 192.168.0.0 now. Validate it.
if ( false !== ip2long( $temp ) )
{
$result = $temp."/".$cidr_bits;
}
}
return $result;
}
/**
* Returns true if the string is a valid CIDR.
*
* @access public
* @param
I agree, and didn't mean to say that I disagreed. This is certainly one of the
top five principles to follow, imo. Too many times, while trouble-shooting,
I've run up on the rock of a binary (meaning: indecipherable) field.
What is the cost of including the binary representation (for indexing)
er.
>
> I'll be interested in the answer, though, from someone with experience.
>
> -- Pete Wilson
> http://www.pwilson.net/
>
>
> --- On Thu, 5/14/09, Jim Lyons wrote:
>
> > From: Jim Lyons
> > Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
>
be interested in the answer, though, from someone with experience.
-- Pete Wilson
http://www.pwilson.net/
--- On Thu, 5/14/09, Jim Lyons wrote:
> From: Jim Lyons
> Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
> To: "Ilia KATZ"
> Cc: mysql@lists.mysql.
e:
> 1. MAC address defined as BIGINT
> 2. MAC address set as primary key
>
> Should I consider changing it to CHAR(12)?
>
> Replies will be appreciated.
> Ilia
>
>
>
>
--
Jim Lyons
Web developer / Database administrator
http://www.weblyons.com
On Thu, 14 May 2009, Ilia KATZ wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi
It depends. You may convert the MAC address to a decimal integer and store
6th byte
the last 2 bytes (of the BIGINT) left unused.
Ilia
From: Fish Kungfu [mailto:fish.kun...@gmail.com]
Sent: Thursday, May 14, 2009 3:54 PM
To: Ilia KATZ
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12
a problem.
>-Original Message-
>From: Ilia KATZ [mailto:ik...@dane-elec.co.il]
>Sent: Thursday, May 14, 2009 9:26 AM
>To: mysql@lists.mysql.com
>Subject: MAC address as primary key - BIGINT or CHAR(12)
>
>Hi.
>Currently I have a table:
>1. MAC address defined as BIGI
On Thursday 14 May 2009 09:53:58 am Fish Kungfu wrote:
> Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
> would say go with CHAR(12).
>
> On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
>
> Hi.
> Currently I have a table:
> 1. MAC add
Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
would say go with CHAR(12).
On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changin
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi,
On Jan 16, 2008 5:13 AM, Richard Heyes <[EMAIL PROTECTED]> wrote:
> > I think it's the same.
>
> I seem to remember that a BIGINT id two INTs tacked together, so how is
> that possible?
MySQL uses BIGINT for most internal math. The data types influence
only how t
I think it's the same.
I seem to remember that a BIGINT id two INTs tacked together, so how is
that possible?
--
Richard Heyes
http://www.websupportsolutions.co.uk
Mailing list management service allowing you to reach your Customers
and increase your sales.
** NOW OFFERING FREE ACCOUN
I think it's the same.
On Jan 16, 2008 6:03 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
> Performance wise, what is a BIGINT like in comparison to an INT on a 32
> bit machine?
>
> Thanks.
>
> --
> Richard Heyes
> http://www.websupportsolutions.co.uk
>
>
Performance wise, what is a BIGINT like in comparison to an INT on a 32
bit machine?
Thanks.
--
Richard Heyes
http://www.websupportsolutions.co.uk
Mailing list management service allowing you to reach your Customers
and increase your sales.
** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON
t and
I loose all all precision witch makes it worthless to me. Is there a way
to let mysql do the conversion since the number I am working with is
48bits and bigint can store 63bits??? I would need to be able to insert
and select it as a binary string?
Yes, you can do this. Probably the best way
y and
convert it to a int in php its too big so it converts it to a float and
I loose all all precision witch makes it worthless to me. Is there a way
to let mysql do the conversion since the number I am working with is
48bits and bigint can store 63bits??? I would need to be able to insert
and sele
and
I loose all all precision witch makes it worthless to me. Is there a way
to let mysql do the conversion since the number I am working with is
48bits and bigint can store 63bits??? I would need to be able to insert
and select it as a binary string?
Thanks for any help.
Byron Albert
--
ata is type BLOB. It is raw data collected. The substr will get
>> the specific bytes I'm interested in. What I need to do, is if the data
>> is <= 8bytes, convert it to a BIGINT, so I can do some masking on the
>> data.
>>
>> So I am writing a UDF to do the job
ytes I'm interested in. What I need to do, is if the data
> is <= 8bytes, convert it to a BIGINT, so I can do some masking on the
> data.
>
> So I am writing a UDF to do the job, but I am apparently unfamiliar with
> the Mysql data types and how I can convert them.
>
f the data
is <= 8bytes, convert it to a BIGINT, so I can do some masking on the
data.
So I am writing a UDF to do the job, but I am apparently unfamiliar with
the Mysql data types and how I can convert them.
In a procedure.
DECLARE fdata_bigint BIGINT UNSIGNED;
SELECT BlobToInt(binary
Looks like you don't have index on `lad_id` field in second table.
So when you do the first query, mysql first does a full scan of 2nd
table, then does eqref lookup for 1st table, which is rather fast
operation. But when you do the left join, it scans first table and for
each value of id does a sca
Ok ... here all the information I could find:
CREATE TABLE `disco_lad` (
`id` bigint(16) unsigned NOT NULL auto_increment,
`import_datum` date default NULL,
`import_zeit` time default NULL,
`gst` smallint(4) unsigned default '0',
`gst_bez` varchar(40) default NULL,
`betrie
Christofer Dutz wrote:
Hi,
I just ran into a very strange problem. I have two simple tables with
BIGINT(16) PKs. The primary table has 7500 records and the secondars has
15000. If I execute:
SELECT * FROM lad JOIN snd ON lad.id = snd.lad_id
The query takes 8 seconds. If I execute this one
Hi,
I just ran into a very strange problem. I have two simple tables with
BIGINT(16) PKs. The primary table has 7500 records and the secondars has
15000. If I execute:
SELECT * FROM lad JOIN snd ON lad.id = snd.lad_id
The query takes 8 seconds. If I execute this one:
SELECT * FROM lad LEFT
Hello.
The behaviour of UNSIGNED BIGINT was correct on my Win2k Professional.
Do you use a mysql command line client or other client software?
mysql> create table bu(a bigint unsigned);
Query OK, 0 rows affected (0.20 sec)
mysql> insert into bu values('1844674407370955161
Hi
I am testing against MySQL 4.1 current release on Windows and there seems to
be a fault with unsigned bigint datatypes.
Using a BIGINT UNSIGNED datatype, the maximum value that will be accepted on
insert query is 9223372036854775807 , which is actually the published
maximum for signed Bigints
I am new to mysql and am converting an existing program. I have
encountered what appears to be a problem with bigints
I have a large integer number (milliseconds since 1970) which is 13
digits. So I tried to store it in a table as a bigint type. Storing
works fine. When I try to retrieve
sorry, I don't know that one. Never have used any version of mysql lower
than 4.04. a suggestion might be to call your 4.0 column an unsigned
bigint, or if possible an unsigned int if the numbers can fit in 32
bits. unsigned means its always positive.
jeff
ps. you may want top "rep
yes it does. we use a bigint(20) for example.
[EMAIL PROTECTED] wrote:
Hi,
I would like to know whether MySql 4.0 supports bigint. If not what
is the corresponding data type that I ccould use if I am imoprting
tables from MySql 3.2 to MySql 4.0
Thanks,
Sharath
--
Jeff Mathis, Ph.D
Hi,
I would like to know whether MySql 4.0 supports bigint. If not what
is the corresponding data type that I ccould use if I am imoprting
tables from MySql 3.2 to MySql 4.0
Thanks,
Sharath
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http
i had the same problem too ... also with blob fields
... never solved!
please keep me informed.
thanks. bye
--- Andre Michel Descombes
<[EMAIL PROTECTED]> ha scritto: > Hi,
>
> I am trying to access a third party MySQL table
> containing a BigInt field,
> using ADO
Hi,
I am trying to access a third party MySQL table containing a BigInt field,
using ADO with a MyOLEDB driver.
The problem is that all this field ever returns are 0's.
I tried using ODBC with the Convert BigInt to Int option but then the
numbers get truncated.
Is there a way around
Dennis <[EMAIL PROTECTED]> wrote on 17.07.2002 20:37:50:
>
>sql query
>
>We have data stored as BIGINT in unix, and there are 32bit unsigned values
>but nothing larger. I would assume if we convert this to integer in win98
>it would seem that values over 31bits w
sql query
We have data stored as BIGINT in unix, and there are 32bit unsigned values
but nothing larger. I would assume if we convert this to integer in win98
it would seem that values over 31bits would be wrong. Are there workarounds
for this? Is this also an issue in later version of
ample.
>
>You have written the following:
>
>
>Is it possible to export 32-bit unsigned values stored as a BIGINT in unix
>as a usable value in Access? there doesnt seem to be an "unsigned" option.
>
>Dennis
---
"You can always store an exact integer value in a BIGINT column by storing
it as a string. In this case, MySQL will perform a string-to-number
conversion that involves no intermediate double representation."
I don't understand this, does this mean that the fastest way to insert
On Tue, 9 Apr 2002, David BORDAS wrote:
> Sent: Tuesday, April 09, 2002 2:14 PM
> Subject: Re: TIMESTAMP(14) or Bigint ??
>
> TIMESTAMP is 4 Bytes and DATETIME is 8 Bytes. So, 4 Bytes difference
> per 5 Millions records = a 20 MB bigger table ...
David
If storage space is a
, and BIGINT of mySQL type ? (sql query)
Do anybody knows the range of MEDIUMINT, and BIGINT type to use
when I do the create table in mySQL ?
Son Nguyen
sql, query
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with
G'day Son Nguyen
> Do anybody knows the range of MEDIUMINT, and BIGINT type to use
> when I do the create table in mySQL ?
>From the manual at http://www.mysql.com/doc/C/o/Column_types.html
MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]
A medium-size integer. The signed range
Do anybody knows the range of MEDIUMINT, and BIGINT type to use
when I do the create table in mySQL ?
Son Nguyen
sql, query
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com
Do anybody knows the range of MEDIUMINT, and BIGINT type to use
when I do the create table in mySQL ?
Son Nguyen
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com
Sent: Tuesday, April 09, 2002 2:14 PM
Subject: Re: TIMESTAMP(14) or Bigint ??
> David,
> I could be wrong but since bigint isn't a date or time oriented data
> type I imagine this would be completely useless to you unless you are
> storing unix timestamps.
In fact i'
Sent: Tuesday, April 09, 2002 2:14 PM
Subject: Re: TIMESTAMP(14) or Bigint ??
> David,
> I could be wrong but since bigint isn't a date or time oriented data
> type I imagine this would be completely useless to you unless you are
> storing unix timestamps.
In fact i'
David,
I could be wrong but since bigint isn't a date or time oriented data
type I imagine this would be completely useless to you unless you are
storing unix timestamps. You also have the option of using datetime data
types. I'm not quite sure what you are asking nor what differenc
ne unique field i can.
So, for this new field that i'll insert and update manually, should i use a
Bigint which required 8 Bytes or a Timestamp(14) with 4 Bytes ?
Timestamp looks great but, can i insert and update it manua
uary 2002 12:27 p.m.
> To: [EMAIL PROTECTED]
> Subject: Re: data type bigint(20)
>
>
> MySQL Gurus,
>
> I'm trying to figure out what the number after the type means for numbers.
> I noticed in someone's code that for the ID field they used bigint(20).
> bigint I t
D]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 3:35 PM
Subject: RE: data type bigint(20)
John,
The number in the parenthsis tells mysql how to format the column when
it goes to display it.. Here is the relevant section of
http://www.mysql.com/doc/N/u/Numeric_types.html:
"A
-Original Message-
> From: John D. Kirkpatrick [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 14, 2002 3:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: data type bigint(20)
>
>
> MySQL Gurus,
>
> I'm trying to figure out what the number after t
MySQL Gurus,
I'm trying to figure out what the number after the type means for numbers.
I noticed in someone's code that for the ID field they used bigint(20).
bigint I thought was fixed at 8 bytes. Does this override the size? 20
bytes??? 20 bits?
T
Bigint int
2147483648 should become -2147483648
2147483649 should become -2147483647
Is there an easy way to do this
if not does anyone know an update query that I could run to convert the
numbers before I do the alter?
Roger Karnouk
[EMAIL PROTECTED] writes:
> >Description:
> max() and possibly other builtins fail due to apparent rounding
> errors for any bigints larger than 53 bits or so. Caveats exist
> in the manual (section 6.2) about bigints larger than 63bit, but
> the actual useful limit (for t
uch lower.
>How-To-Repeat:
$ echo '2^53' | bc
9007199254740992
mysql> create table big_nums ( big bigint );
Query OK, 0 rows affected (0.00 sec)
mysql> insert into big_nums (big) values (9007199254740992);
Query OK, 1
Hi,
I found a bug about bigint and max(), here is error result caused by
bigint & max():
--
mysql> create table dick ( big bigint );
Query OK, 0 rows affected (0.00 sec)
mysql> insert into d
Hi,
I found a bug about bigint and max(), here is error result caused by
bigint & max():
--
mysql> create table dick ( big bigint );
Query OK, 0 rows affected (0.00 sec)
mysql> insert into d
hi all
i have make sure there is a bug of mysql with mysql-3.23.32
repeat this bug.
CREATE TABLE A (
B bigint(20) unsigned DEFAULT '0' NOT NULL,
value bigint(20) unsigned DEFAULT '0' NOT NULL,
PRIMARY KEY (B)
);
*p.s the same with take off primary key
u see this error. We ended up writing a
wrapper around the MySQL object to test to see if the value is 100% numeric
and if so not quote it. I'm not sure why MySQL can't reliably compare a
bigint with quotes around it, but that is definitely the problem. Despite
the docs, we use a lot
On Tue, Feb 20, 2001 at 06:56:28PM +0800, chchen wrote:
> hi all
>
> i use mysql-3.23.32
>
> my project need to use unsigned Bigint as a primary key.
> but when i insert many rows in this table.
> sometimes it will error with Duplicate such like
>
>
First, i am really sorry about that.
my fields is quite simple.
CREATE TABLE TEST (
A bigint(20) unsigned DEFAULT '0' NOT NULL,
C0 bigint(20) unsigned DEFAULT '0' NOT NULL,
C1 bigint(20) unsigned DEFAULT '0' NOT NULL,
C2 bigint(20) unsigned DEFAULT
Firstly, why do you have quotes around the numbers? I thought you said it
was bigint, not a string?
Secondly, if you are going reply/repost to the list, could you please
simplify it a bit. Provide field names, etc. Your insert is very difficult
to figure out especially with unmatched brackets
hi all
i use mysql-3.23.32
my project need to use unsigned Bigint as a primary key.
but when i insert many rows in this table.
sometimes it will error with Duplicate such like
insert into Table
values('9231852172526977164',0,0,52056,0,0,0,0,0,52056,0,0,0,0,0,0,0,11,0,'184
river, because I used the same MyODBC driver under Windows 98, and I had no
problems whatsoever. Yes, I'm using ADO -- that explains why Access still
works. Somehow, there's some ADO functionality in Windows ME and 2000 that
does not recognize BIGINT datatypes. It can't be anythin
nality in Windows ME and 2000 that
does not recognize BIGINT datatypes. It can't be anything in VB, since in
both cases I'm using VB 6.0 with service pak 4. Only thing that changed was
the O/S from Win 98 to Windows ME and Windows 2000. Everything else was the
same, same version My
ws ME / 2000 VB problem with BIGINT data type
Thank you, Quentin,
Hey, does anyone know where the problem lies here? Where in Windows ME /
2000? Why does Access still import OK? Is there something that needs to be
done with MyODBC to handle BIGINT types in the future?
Thank you,
Laszlo
- Ori
Thank you, Quentin,
Hey, does anyone know where the problem lies here? Where in Windows ME /
2000? Why does Access still import OK? Is there something that needs to be
done with MyODBC to handle BIGINT types in the future?
Thank you,
Laszlo
- Original Message -
From: "Quentin Be
oblem with BIGINT data type
I isolated the problem because if I do a
"select * from table" -- I get the error.
but if I do "select field1, field3, field4 from table", where I leave out
the BIGINT column, I'm fine.
and when I do a "select field2 form table" where fie
I isolated the problem because if I do a
"select * from table" -- I get the error.
but if I do "select field1, field3, field4 from table", where I leave out
the BIGINT column, I'm fine.
and when I do a "select field2 form table" where field2 is the BIGINT
colu
I wrote to the list earlier on the above problem. I had a VB app that accessed a
mysql (on Linux) table through MyODBC. Apparently the problem is that the new ODBC
connection providers in Windows ME / 2000 do not like the BIGINT datatype. Yet,
strangely, MS Access 97 can import the data
70 matches
Mail list logo
