August 13, 2007 at 5:57 pm
Hi All,
I stored IP address into a field in a table in sql2k. The field is varchar (20), and the data is without dot.
Ex: 1821682521
When I query the table directly:
select IP from mytable where ip = '1821682521'
it returns data for me. But if I link the table with another table which also has IP field, it returns nothing for me even thoughthe other table has exact the same IP:
select a.ip, b.ip
from mytable a, mytable2 b
where a.ip = b.ip
Does anyone know why is that?
Thanks in advance for any inputs.
Minh Vu
August 13, 2007 at 6:15 pm
What do you get when you run the following?
SELECT '|'+IP+'|', 'A' AS Ind FROM MyTable WHERE IP = '1821682521'
UNION ALL
SELECT '|'+IP+'|', 'B' AS Ind FROM MyTable2 WHERE IP = '1821682521'
Also, why did you you remove the periods without adding leading zeros to each octet? You've made it possible to have a dupe that shouldn't be counted as a dupe
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 7:42 pm
Actually IP address is 4-byte value.
And it must be stored in BINARY(4) column.
Nothing to do with any kind of varchar here.
As soon as you've fixed you table design you not gonna have problems with queries.
_____________
Code for TallyGenerator
August 13, 2007 at 8:02 pm
As Jeff and Sergiy have identified, your data type is doinked. you should have either kept the full IP address, or converted it to an int or big int.
how do you know which value this is:
'1821682521' = 182.168.25.21 or 182.168.252.1
you can store an ip as an int, but a great article from david pool suggests putting it in 4 fields as small ints:
storing IP's in SQL Server:http://www.sqlservercentral.com/columnists/dpoole/2871.asp
Lowell
August 13, 2007 at 9:04 pm
With the PARSENAME function, there's no need even for that. PARSENAME (see Books Online) was developed almost soley for the purpose of interogating IP Addresses provided that the dots are left intact.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 14, 2007 at 8:12 am
damn I learned something new again. thanks Jeff;
Here's some crappy sample code; you'd probably want to convert to int in order to store the data:
declare @IP varchar(20)
SET @IP = '192.168.1.65'
select
PARSENAME(@IP,4) AS IP1,
PARSENAME(@IP,3) AS IP2,
PARSENAME(@IP,2) AS IP3,
PARSENAME(@IP,1) AS IP4
results:
IP1 | IP2 | IP3 | IP4 |
192 | 168 | 1 | 65 |
Lowell
August 14, 2007 at 8:18 am
Thanks for the feedback, Lowell
One more thing... you said the article explains how to save each "field" as SMALLINT. Even that is not necessary because each "field" of an IP address can only go from 0 to 255... that means TINYINT will work just fine (each is a single byte like Serqiy said).
--Jeff Moden
Change is inevitable... Change for the better is not.
August 14, 2007 at 8:19 am
That can also be used as a split function (when the dba doesn't want to have one on the server). Of course, that works only if you only need to have 4 items or less sent in the string (and you can use replace to change the delemiter from comma (or whatever it is) to a period for the function to work.
August 14, 2007 at 9:29 am
Actually, PARSENAME was not designed for parsing IP Addresses, it just happens to work, From BOL:
Returns the specified part of an object name. Parts of an object that can be retrieved are the object name, owner name, database name, and server name.
Just to keep the record straight.
August 14, 2007 at 4:39 pm
Yes, not specifically for IP addresses, I use it to split up the text version of a performance counter name.
Anyway back on topic, did we solve the OP's problem
--------------------
Colt 45 - the original point and click interface
August 14, 2007 at 6:16 pm
Yeah... Sorry about that... was thinking about something different and didn't double check.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply