Showing posts with label bit. Show all posts
Showing posts with label bit. Show all posts

Friday, March 23, 2012

Login Failed for user '(null)' - Multiple Servers

Greets,
I realize that this is a common issue--however, the situation seems a bit
different. Or maybe I'm naive :) Anyway, I have two servers, one hosting
the data. The other only has what it takes to run SRS.
I loaded visual studio on the SRS server for ease of use. From there, I can
create, preview, and deploy any report I like. However, even from the local
IE, I can seem to pass through the authentication. I have removed anonymous
access to the reporting website--hoping to force authentication. I have
looked at all the Web.config files, all are set for impersonation = 'true'.
What am I missing here?
Thanks!Hi Joseph,
Thank you for your posting!
My understanding of this issue is: You can not view the Report via URL and
you get the Login Failed for user '(null)' error. If I misunderstood your
concern, please feel free to let me know.
It seems that the datasource credential does not set correctly. Please try
to do the following:
1. Open Report Manager via URL.
2. Find the report and click it.
3. Click Properties, and then click Data Sources.
4. If you are using custom data source, please click the Credentials
supplied by the user running the report.
5. If you are using shared data source, then go to the datasource, and
click it. Also click the Credentials supplied by the user running the
report.
6. If the login is a Windows Credential, please check the Use as Windows
credentials when connecting to the data source.
Please let me know the result so that I can provide further assistance.
Thank you!
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks for the response,
However, I do not believe that this is the issue. I am using Windows
authentication only--so as far as I can determine, no creditials can be
specified. Also, the datasource works FINE inside visual studio.
This is an IIS issue, probably having to do with one of two things:
1. The SRS Servers's computer account needs to be Trusted for Delegation
2. I need to be running the SQL services as a Domain User account...this
second one is a little suspect, because I am using the database with an
Access 2003 frontend, and all the Windows authentication works well.
Any other thoughts?
"Wei Lu" <weilu@.online.microsoft.com> wrote in message
news:JOeiC7PlGHA.2260@.TK2MSFTNGXA01.phx.gbl...
> Hi Joseph,
> Thank you for your posting!
> My understanding of this issue is: You can not view the Report via URL and
> you get the Login Failed for user '(null)' error. If I misunderstood your
> concern, please feel free to let me know.
> It seems that the datasource credential does not set correctly. Please try
> to do the following:
> 1. Open Report Manager via URL.
> 2. Find the report and click it.
> 3. Click Properties, and then click Data Sources.
> 4. If you are using custom data source, please click the Credentials
> supplied by the user running the report.
> 5. If you are using shared data source, then go to the datasource, and
> click it. Also click the Credentials supplied by the user running the
> report.
> 6. If the login is a Windows Credential, please check the Use as Windows
> credentials when connecting to the data source.
> Please let me know the result so that I can provide further assistance.
> Thank you!
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>|||Hi Joseph,
Thank you for the information and clarification.
Let me know some information.
1. Could you access the Report Manager correctly?
2. Could you access the Report Server correctly?
3. If you could access the above site correctly, I don't think you need to
change the SQL Reporting Services start up account. Please try the method I
provided in the previous post and you could supply the Windows Credential
you use to connect to your database. ( I think it will be your domain
account or you windows login account. )
4. If you could not access the above site correctly, please let me know the
error message and so that I can provide further assistance. Thank you!
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi Joseph,
Have you get any chance to collect the information? Please feel free to let
me know if you have any question. Thank you!
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||I've had the same problem with my reports, and my solution seems to have
been the simplest:
When you deploy a report from VS, the data source sometimes gets messed up.
I created a new data source in Report Manager and changed my report to use
this one instead. Both are using Windows Integrated Authentication. My
report didn't work with the data source generated by VS, but it worked
without any problems with the new data source.
You can still upload reports to the server, and they will use the new data
source, so you only have to do this once (at least once with every new
report).
I don't know why the data sources gets messed up. But it seems to fix my
problem. I found the clue in a news group post, so it has probably solved
the problem for someone else as well.
Kaisa M. Lindahl Lervik
"Joseph Baxter" <tanstaafl32@.newsgroups.nospam> wrote in message
news:uDTfE9IlGHA.1320@.TK2MSFTNGP04.phx.gbl...
> Greets,
> I realize that this is a common issue--however, the situation seems a bit
> different. Or maybe I'm naive :) Anyway, I have two servers, one hosting
> the data. The other only has what it takes to run SRS.
> I loaded visual studio on the SRS server for ease of use. From there, I
> can create, preview, and deploy any report I like. However, even from the
> local IE, I can seem to pass through the authentication. I have removed
> anonymous access to the reporting website--hoping to force authentication.
> I have looked at all the Web.config files, all are set for impersonation => 'true'.
> What am I missing here?
> Thanks!
>

Wednesday, March 7, 2012

Logical functions in SELECT clause

Hi,

this ought to be elementary: I want to select the logical inverse of a bit type column. The online help tells me

Syntax [ NOT ] boolean_expression
Arguments

boolean_expression

Is any valid Microsoft? SQL Server? Boolean expression.

Result Value

NOT reverses the value of any Boolean expression.

The way I read this I should be able to then simply SELECT NOT bit_col, yet I get a syntax error when I try to do simply

SELECT (NOT CAST(1 AS BIT))

Arrrrgh! I've tried some syntactical variations on the theme, but it seems the not function just doesn't work in the SELECT clause, only in the WHERE clause.

Of course, I can get the result I want using

select case bit_col when 1 then 0 else 1 end as 'inverted_bit_col';

But, is there really no more elegant and well-performing way to select an inverted bit column than using a CASE?

Hi

I have tried ^ (Bitwise Exclusive OR) with 1 and it worked.

CREATE TABLE #tmp ( bitNumber BIT NOT NULL )

INSERT INTO #TMP VALUES (1)
INSERT INTO #TMP VALUES (0)

SELECT bitNumber, bitNumber ^ 1 FROM #TMP

The values in (bitNumber ^ 1 ) are reversed from bitNumber

NB.

|||Note that the bit field, although commonly used as a boolean field, is a bit field and holds values of 1 and 0, not true and false (although in most programming languages these values are interchangeable). But, as far as I know, a bit field does not evaluate to a boolean expression, and thus cannot be used as such. What you want is to use a bitwise operator as illustrated well above. Someone please correct me if I am wrong in this assumption.|||

But, is there really no more elegant and well-performing way to select an inverted bit column than using a CASE?

Define elegant and well-performing? Are you having performance problems with:

select case bit_col when 1 then 0 else 1 end as 'inverted_bit_col'

I can't see it being a performance question, and truthfully it is as elegant as any other way of doing it (a function would be better, so you might write a CLR function to do it, but it would be overkill. I like this way because it is clear what you are doing. you can also us the modulus function to "flip the bit":

(@.bit + 1) % 2

I tried each way using the following test ant the results were very much the same result.

set nocount on
create table testBit
(
bitCol bit
)
go
insert into testBit
select cast( case when rand() < .5 then 0 else 1 end as bit)
go 400000 --works in 2005. For 2000 you will need to write a loop

DBCC FREEPROCCACHE
declare @.getdate datetime
set @.getdate = getdate()
declare @.test table (bitCol bit)
insert into @.test
select (bitCol + 1) % 2
from testBit
select datediff(ms,@.getdate,getdate()) /1000.0 as [seconds (bitCol + 1) % 2]
go
DBCC FREEPROCCACHE
declare @.getdate datetime
set @.getdate = getdate()
declare @.test table (bitCol bit)
insert into @.test
select (bitCol ^ 1 )
from testBit
select datediff(ms,@.getdate,getdate()) /1000.0 as [seconds (bitCol ^ 1 )]
go
DBCC FREEPROCCACHE
declare @.getdate datetime
set @.getdate = getdate()
declare @.test table (bitCol bit)
insert into @.test
select case bitCol when 1 then 0 else 1 end
from testBit
select datediff(ms,@.getdate,getdate()) /1000.0 as [seconds case bitCol when 1 then 0 else 1 end]
go

Not scientific, but it does show that there is very little differnece between the different styles.

|||XOR does the trick, yes. Thanks!|||

I get it; in SQL Server, bit is not boolean. When I connect using ADO.NET (SqlClient, the native provider) the bit type maps to boolean, and I short-circuited...

How can I test (directly in query analyzer) what the type of the expression

bit_col ^ 1

is, when bit_col is of type bit? I still want the result to map to System.Boolean - I presume I'd have to cast the result as bit, but is there a way to make sql server tell me the type of an expression?

Thanks for the tip!

|||

Thank you for a very informative and complete reply.

I basically just held some prejudice against the case statements. I'm now wondering if that was completely without foundation...

Thanks!

|||

well.. we all know from boolean algebra that XOR is much lighter then ADD and especially division by modulo and processing script's CASE

It is my penny if we are talking about performance, let say we want to process 20 millions records :) I think the difference will be significant.

|||You can invert a bit with the ~ operator.|||I gotta be honest with you. If you are twiddling bits over 20 million rows you have a lot more problems than whether CASE works faster than ~ or modulo, or the other one :)

Logical connections very different from user connections

Hi,
We are administering a 64 bit sql 2005 instance that averages 400
transactions per second or so during business hours. The server is
performing quite well, but recently we've been seeing some performance
tick data that I don't understand.
In the SQLServer:General Statistics category, the server reports 270
logical connections. However, the User Connections perf ticks returns
491 connections. I am at a loss to explain the difference between the
two values. We consider 270 client connections to be an acceptable
number, but 491 is significantly higher than we would like to see.
I've searched for documentation explaining the difference between the
two perf ticks, but I haven't had any luck. I'm looking for a) some
information on what the difference between the two ticks is, and b)
some information that will help me determine if the discrepancy is
important.
Any advice or pointers as to where I could look next would be greatly
appreciated.
Sean Reilly
Software Architect
Point2 Technologies, Inc
(306) 955-1855Doesn't SQL Server group user connections based on certain conditions?
This would explain the difference.
Jim.
"Sean Reilly" wrote:

> Hi,
> We are administering a 64 bit sql 2005 instance that averages 400
> transactions per second or so during business hours. The server is
> performing quite well, but recently we've been seeing some performance
> tick data that I don't understand.
> In the SQLServer:General Statistics category, the server reports 270
> logical connections. However, the User Connections perf ticks returns
> 491 connections. I am at a loss to explain the difference between the
> two values. We consider 270 client connections to be an acceptable
> number, but 491 is significantly higher than we would like to see.
> I've searched for documentation explaining the difference between the
> two perf ticks, but I haven't had any luck. I'm looking for a) some
> information on what the difference between the two ticks is, and b)
> some information that will help me determine if the discrepancy is
> important.
> Any advice or pointers as to where I could look next would be greatly
> appreciated.
> Sean Reilly
> Software Architect
> Point2 Technologies, Inc
> (306) 955-1855
>|||Jim,
I hope that something like this does explain what I'm seeing. Do you
have any ideas as to what those conditions might be?
Thanks,
Sean|||From BOL:
"Connections can be shared among users. Users running OLE DB applications
need a connection for each open connection object, users running Open
Database Connectivity (ODBC) applications need a connection for each active
connection handle in the application, and users running DB-Library
applications need one connection for each process started that calls the
DB-Library dbopen function."
I'm not sure you have a lot of control over these features, but it would be
worth investigation "Connections" in any MS publications.
"Sean Reilly" wrote:

> Jim,
> I hope that something like this does explain what I'm seeing. Do you
> have any ideas as to what those conditions might be?
> Thanks,
> Sean
>|||Jim,
I'm pretty sure that the BOL entry you quoted refers to the client end
of the connection. I believe that Ole DB, ODBC and DB-Library
connections are all the same kind of connection from the server's
perspective.
A further data point for anyone who may be interested: when I use the
activity montior in SSMS, the number of connections reported matches
the smaller perf tick value (logical connections).

Logical connections very different from user connections

Hi,
We are administering a 64 bit sql 2005 instance that averages 400
transactions per second or so during business hours. The server is
performing quite well, but recently we've been seeing some performance
tick data that I don't understand.
In the SQLServer:General Statistics category, the server reports 270
logical connections. However, the User Connections perf ticks returns
491 connections. I am at a loss to explain the difference between the
two values. We consider 270 client connections to be an acceptable
number, but 491 is significantly higher than we would like to see.
I've searched for documentation explaining the difference between the
two perf ticks, but I haven't had any luck. I'm looking for a) some
information on what the difference between the two ticks is, and b)
some information that will help me determine if the discrepancy is
important.
Any advice or pointers as to where I could look next would be greatly
appreciated.
Sean Reilly
Software Architect
Point2 Technologies, Inc
(306) 955-1855Doesn't SQL Server group user connections based on certain conditions?
This would explain the difference.
Jim.
"Sean Reilly" wrote:
> Hi,
> We are administering a 64 bit sql 2005 instance that averages 400
> transactions per second or so during business hours. The server is
> performing quite well, but recently we've been seeing some performance
> tick data that I don't understand.
> In the SQLServer:General Statistics category, the server reports 270
> logical connections. However, the User Connections perf ticks returns
> 491 connections. I am at a loss to explain the difference between the
> two values. We consider 270 client connections to be an acceptable
> number, but 491 is significantly higher than we would like to see.
> I've searched for documentation explaining the difference between the
> two perf ticks, but I haven't had any luck. I'm looking for a) some
> information on what the difference between the two ticks is, and b)
> some information that will help me determine if the discrepancy is
> important.
> Any advice or pointers as to where I could look next would be greatly
> appreciated.
> Sean Reilly
> Software Architect
> Point2 Technologies, Inc
> (306) 955-1855
>|||Jim,
I hope that something like this does explain what I'm seeing. Do you
have any ideas as to what those conditions might be?
Thanks,
Sean|||From BOL:
"Connections can be shared among users. Users running OLE DB applications
need a connection for each open connection object, users running Open
Database Connectivity (ODBC) applications need a connection for each active
connection handle in the application, and users running DB-Library
applications need one connection for each process started that calls the
DB-Library dbopen function."
I'm not sure you have a lot of control over these features, but it would be
worth investigation "Connections" in any MS publications.
"Sean Reilly" wrote:
> Jim,
> I hope that something like this does explain what I'm seeing. Do you
> have any ideas as to what those conditions might be?
> Thanks,
> Sean
>|||Jim,
I'm pretty sure that the BOL entry you quoted refers to the client end
of the connection. I believe that Ole DB, ODBC and DB-Library
connections are all the same kind of connection from the server's
perspective.
A further data point for anyone who may be interested: when I use the
activity montior in SSMS, the number of connections reported matches
the smaller perf tick value (logical connections).

logical and

Hi,
I want to do a logical comparison between two tinyint-columns in a select
statement.
With logical I mean: if a bit in the tinyints are both 1 then comparison is
true.
00001000 and 11000001 = false
10101010 and 00000010=true
Can this be done in SQLServer?
Thanks
Frank
The bitwise AND logical operator in SQL Server is '&'. This expects integer
values. Converting your binary values to integer:
IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
See Bitwize AND in the Books Online for more information.
Hope this helps.
Dan Guzman
SQL Server MVP
"Frank" <frank@.frank.com> wrote in message
news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
> Hi,
> I want to do a logical comparison between two tinyint-columns in a select
> statement.
> With logical I mean: if a bit in the tinyints are both 1 then comparison
> is true.
> 00001000 and 11000001 = false
> 10101010 and 00000010=true
> Can this be done in SQLServer?
> Thanks
> Frank
>
|||GREAT!!!!!
Frank
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> schreef in bericht
news:uaWOg4K%23EHA.1296@.TK2MSFTNGP10.phx.gbl...
> The bitwise AND logical operator in SQL Server is '&'. This expects
> integer values. Converting your binary values to integer:
> IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
> IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
> See Bitwize AND in the Books Online for more information.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Frank" <frank@.frank.com> wrote in message
> news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
>
|||Frank,
Dan pointed you in the right direction, and I'll just note that
to see if X and Y have a common bit set, compare X & Y
with 0.
Steve Kass
Drew University
Frank wrote:

>Hi,
>I want to do a logical comparison between two tinyint-columns in a select
>statement.
>With logical I mean: if a bit in the tinyints are both 1 then comparison is
>true.
>00001000 and 11000001 = false
>10101010 and 00000010=true
>Can this be done in SQLServer?
>Thanks
>Frank
>
>
|||"Steve Kass" <skass@.drew.edu> wrote in message
news:uB%23xjUL%23EHA.1188@.tk2msftngp13.phx.gbl...
> Frank,
> Dan pointed you in the right direction, and I'll just note that
> to see if X and Y have a common bit set, compare X & Y
> with 0.
> Steve Kass
> Drew University
>
If X & Y = 0 then you have no bits in common.
X 1001
Y 0110
======
0000
IF X & Y = Y then you have Y bits in common.
X 1001
Y 0001
======
0001 <-- Same as Y
IF X & Y > 0 then you have at lest some bits in common, but not necessarily
all of them.
X 1001
Y 0011
======
0001 > 0 At least one bit in common.
Rick Sawtell
MCT, MCSD, MCDBA

logical and

Hi,
I want to do a logical comparison between two tinyint-columns in a select
statement.
With logical I mean: if a bit in the tinyints are both 1 then comparison is
true.
00001000 and 11000001 = false
10101010 and 00000010=true
Can this be done in SQLServer?
Thanks
FrankThe bitwise AND logical operator in SQL Server is '&'. This expects integer
values. Converting your binary values to integer:
IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
See Bitwize AND in the Books Online for more information.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Frank" <frank@.frank.com> wrote in message
news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
> Hi,
> I want to do a logical comparison between two tinyint-columns in a select
> statement.
> With logical I mean: if a bit in the tinyints are both 1 then comparison
> is true.
> 00001000 and 11000001 = false
> 10101010 and 00000010=true
> Can this be done in SQLServer?
> Thanks
> Frank
>|||GREAT!!!!!
Frank
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> schreef in bericht
news:uaWOg4K%23EHA.1296@.TK2MSFTNGP10.phx.gbl...
> The bitwise AND logical operator in SQL Server is '&'. This expects
> integer values. Converting your binary values to integer:
> IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
> IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
> See Bitwize AND in the Books Online for more information.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Frank" <frank@.frank.com> wrote in message
> news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
>> Hi,
>> I want to do a logical comparison between two tinyint-columns in a select
>> statement.
>> With logical I mean: if a bit in the tinyints are both 1 then comparison
>> is true.
>> 00001000 and 11000001 = false
>> 10101010 and 00000010=true
>> Can this be done in SQLServer?
>> Thanks
>> Frank
>>
>|||Frank,
Dan pointed you in the right direction, and I'll just note that
to see if X and Y have a common bit set, compare X & Y
with 0.
Steve Kass
Drew University
Frank wrote:
>Hi,
>I want to do a logical comparison between two tinyint-columns in a select
>statement.
>With logical I mean: if a bit in the tinyints are both 1 then comparison is
>true.
>00001000 and 11000001 = false
>10101010 and 00000010=true
>Can this be done in SQLServer?
>Thanks
>Frank
>
>|||"Steve Kass" <skass@.drew.edu> wrote in message
news:uB%23xjUL%23EHA.1188@.tk2msftngp13.phx.gbl...
> Frank,
> Dan pointed you in the right direction, and I'll just note that
> to see if X and Y have a common bit set, compare X & Y
> with 0.
> Steve Kass
> Drew University
>
If X & Y = 0 then you have no bits in common.
X 1001
Y 0110
====== 0000
IF X & Y = Y then you have Y bits in common.
X 1001
Y 0001
====== 0001 <-- Same as Y
IF X & Y > 0 then you have at lest some bits in common, but not necessarily
all of them.
X 1001
Y 0011
====== 0001 > 0 At least one bit in common.
Rick Sawtell
MCT, MCSD, MCDBA

Friday, February 24, 2012

logical and

Hi,
I want to do a logical comparison between two tinyint-columns in a select
statement.
With logical I mean: if a bit in the tinyints are both 1 then comparison is
true.
00001000 and 11000001 = false
10101010 and 00000010=true
Can this be done in SQLServer?
Thanks
FrankThe bitwise AND logical operator in SQL Server is '&'. This expects integer
values. Converting your binary values to integer:
IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
See Bitwize AND in the Books Online for more information.
Hope this helps.
Dan Guzman
SQL Server MVP
"Frank" <frank@.frank.com> wrote in message
news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
> Hi,
> I want to do a logical comparison between two tinyint-columns in a select
> statement.
> With logical I mean: if a bit in the tinyints are both 1 then comparison
> is true.
> 00001000 and 11000001 = false
> 10101010 and 00000010=true
> Can this be done in SQLServer?
> Thanks
> Frank
>|||GREAT!!!!!
Frank
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> schreef in bericht
news:uaWOg4K%23EHA.1296@.TK2MSFTNGP10.phx.gbl...
> The bitwise AND logical operator in SQL Server is '&'. This expects
> integer values. Converting your binary values to integer:
> IF 8 & 193 = 193 PRINT 'true' ELSE PRINT 'false'
> IF 170 & 2 = 2 PRINT 'true' ELSE PRINT 'false'
> See Bitwize AND in the Books Online for more information.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Frank" <frank@.frank.com> wrote in message
> news:41e50fbc$0$6211$e4fe514c@.news.xs4all.nl...
>|||Frank,
Dan pointed you in the right direction, and I'll just note that
to see if X and Y have a common bit set, compare X & Y
with 0.
Steve Kass
Drew University
Frank wrote:

>Hi,
>I want to do a logical comparison between two tinyint-columns in a select
>statement.
>With logical I mean: if a bit in the tinyints are both 1 then comparison is
>true.
>00001000 and 11000001 = false
>10101010 and 00000010=true
>Can this be done in SQLServer?
>Thanks
>Frank
>
>|||"Steve Kass" <skass@.drew.edu> wrote in message
news:uB%23xjUL%23EHA.1188@.tk2msftngp13.phx.gbl...
> Frank,
> Dan pointed you in the right direction, and I'll just note that
> to see if X and Y have a common bit set, compare X & Y
> with 0.
> Steve Kass
> Drew University
>
If X & Y = 0 then you have no bits in common.
X 1001
Y 0110
======
0000
IF X & Y = Y then you have Y bits in common.
X 1001
Y 0001
======
0001 <-- Same as Y
IF X & Y > 0 then you have at lest some bits in common, but not necessarily
all of them.
X 1001
Y 0011
======
0001 > 0 At least one bit in common.
Rick Sawtell
MCT, MCSD, MCDBA