Of course this will make my SQL Statement valid but the problem is that I have to put additional trigger on the table.

The use -case scenario is like

INSERT INTO groups...

HierarchyID is good for defining trees but actually it is incredibly unpleasent when it comes to rearrange the tree. And hierarchy here is not a tree - it's just DAG.

And...

The funny thing about this whole topic is: while INT is almost surely the best way to store IPv4 data type in most scenarios, it is interesting why there is...

nicholastjh (8/19/2009)

---

Nice article. Very informative.

But at the final function where 128 is subtracted from the result of ParseName, before being multiplied by 16777216 (2^24), could potentially yield negative results, if...

Again - good idea.

I will try to test them all on wednesday (or at least initiate the data migration to make tests possible 😉 ). I will definitely post some...

Anyway - worth trying. I think I will mirror INT version in BIGINT table and compare some real life stats.

I understand. My point is - probability of getting 12 bits in 6 BIGINTS (when I have 5000 bits) is quite low without good statistics. I don't have good statistics...

Well yes - if all the bits are actually in one column. An extremely rare case.

About my boss... well - he also is IT guy. He just don't trust CLR...

As we are working on 32-bit environment I've seen no advantage of BIGINT over INT as all bit-wise operations are made, as I recall, on 32bit segments. So more or...

I tinkered with this idea a little about 2 weeks age (I will continue later; not enough time right now) but:

any combination of and/or is possible if you use union/intersect...

Wow, thanks for the solution. It makes code look simpler.

Do you know why the first syntax returns error? Shouldn't they be equivalent or s.t.?

As I stated previously - it works fine with POWER(-2,29); It crushes only with POWER(-2,31)

If it works fine with you - well. Something is unfortunately wrong with my configuration

Try to link remote server and do it with

[remote_computer].[database].[schema].

instead of

[database].[schema].

I checked it three times - it is just INT, not BIGINT. Besides i think BIGINT is actually compatible. Anyway - this is just ordinary INT column. And also ...

I think that you can run out of memory with temporary table.