Sorting ip address for dynamic table

Not trying to be rude or anything, but I need and want them to be sorted in
order.

regards, Mark

[q]Originally posted by: Newsgroup User
relecom,
This question you have is pretty complicated by the amount of posts needed
to get an answer.
Could I ask what is so important to sort on an IP Address?

Cheers



"relecom" <webforumsuser (AT) macromedia (DOT) com> wrote

I am trying to sort an ip address coloumn, and it't working but not sorting
properly.

SQL:

SELECT radio_ip
FROM sc_survey
WHERE radio_ip LIKE MMColParam%
ORDER BY radio_ip ASC

as you cvan see it's sorting, but not in order

what is the proper format to sort ip addresses in actual order?

thanks, Mark

[/q]

This question you have is pretty complicated by the amount of posts needed
to get an answer.

The number of posts does not reflect the complexity of the problem. It is a
relatively simple issue that only took a few minutes to solve. Most of the
posts are a result of poor communication and lack of understanding.

can I make this work with a stored procedure in dreamweaver?
that might make things easier, then just call the stored procedure when
listing the ip addresses.

Sure, if your version of Access supports stored procedures. Personally, I
would just use an Access query using the code I provided earlier. You can
reference Access queries from DW server behaviors just as if they were tables.
You can even include addition where clause filters in the DW recordset.

I will go with that then.

thanks, Mark

[q]Originally posted by: bregent

can I make this work with a stored procedure in dreamweaver?
that might make things easier, then just call the stored procedure when
listing the ip addresses.

Sure, if your version of Access supports stored procedures. Personally, I
would just use an Access query using the code I provided earlier. You can
reference Access queries from DW server behaviors just as if they were tables.
You can even include addition where clause filters in the DW recordset.[/q]

..oO(bregent)

Sure, if your version of Access supports stored procedures. Personally, I
would just use an Access query using the code I provided earlier.

I consider that query very complex and error-prone. With all these
nested INSTR() calls it also looks quite inefficient. For me a stored
procedure would be the better way in this case. Cleaner and more
efficient code and just a simple call in the final query.

But of course that's just IMHO, YMMV.

Micha

I consider that query very complex and error-prone.

Well it's not pretty. But error prone? It works. Why would it suddenly stop
working?

With all these nested INSTR() calls it also looks quite inefficient.

Maybe, but you probably wouldn't notice any performance issues until you get
to many 10's of thousands of rows. I'm not sure what the OP has in mind for row
counts.
And unless you have different functions available to use within the sproc,
it's not really going to be any better.
What would you do inside a sproc to make it more efficient?
It's possible that MS Access sprocs in newer version support transact sql, in
which case PARSENAME might be available to use. In that case, it might be worth
pursuing.

..oO(bregent)

I consider that query very complex and error-prone.

Well it's not pretty. But error prone?

IMHO yes. If you have to copy such a monster from somewhere or even have
to make adjustments, such code is just painful and very hard to read. At
least for me.

It works. Why would it suddenly stop
working?

It wouldn't, but first you have to get it correctly and in the way you
want into the DB.

With all these nested INSTR() calls it also looks quite inefficient.

Maybe, but you probably wouldn't notice any performance issues until you get
to many 10's of thousands of rows. I'm not sure what the OP has in mind for row
counts.
And unless you have different functions available to use within the sproc,
it's not really going to be any better.
What would you do inside a sproc to make it more efficient?

Good question.

At least I have variables, which can be really helpful for many
algorithms. Additionally there might be other languages available for
writing SPs instead of just pure SQL, which might allow to simply split
the string at the commas and then perform the calculations. Just a few
operations in maybe 2 or 3 lines of code. That's what I was thinking of
in my last reply. And even if there's just pure SQL in the SP, I would
still prefer that, because it allows for nicer queries and reusability.

But I have to admit that I haven't used SPs yet, because I didn't need
them.

Micha