[quoted text, click to view]

Not trying to answer for Adam, of course ... just chiming in:

A char is slightly more "human-readable" than a bit.

Using a char instead of a bit forcibly reminds the programmer that a bit is
NOT a boolean and will not react like a boolean in SQL code. (There's no
AND/OR/NOT, for instance.)

[quoted text, click to view]
I agree with Adam. Chars are easy to handle in forms.
/Fredrik

And if you use CHAR(1) you can use some more meaningful codes as well. For
example, if you have a column in your Employees table that indicates whether
an employee is full time or part time, there are a number of different ways
to define that:

Is_FullTime bit,
Is_FullTime CHAR(1) CHECK(Is_FullTime IN ('Y', 'N')
FullTime_PartTime CHAR(1) CHECK(FullTime_PartTime IN ('F', 'P'))

My preference is the last.

--
Jacco Schalkwijk
SQL Server MVP


[quoted text, click to view]

Bit data type.

Supports NULL, 0 and 1. Matches a Boolean data type for all languages except
VB (VB is brain dead enough to think -1 is an appropriate value for True)

Normal programming rules apply: Evaluate for False (0) and you know what you
get.

Problem with CHAR is that in a internationalized environment, type
conversion between code pages involves a lot of work.

Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

[quoted text, click to view]

[quoted text, click to view]


My sentiments exactly -- I give you full permission to answer for me
from now on :-)


--
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--

Hi Jim,

We use smallint. We treat 0 as false and anything else as true. Allows us to
deal with differing languages that store values differently. It also is
indexable which wasn't the case with bit until SS2000.

HTH,

--
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com

[quoted text, click to view]

[quoted text, click to view]
Assembly language agrees with VB.

FALSE EQU 0

[quoted text, click to view]

Brain dead assembler. Everyone knows God developed C on a PDP.
Next you'll be suggesting hardware-level partitioning of the memory
space to prevent viruses running in the data segments.

(david)

[quoted text, click to view]

[quoted text, click to view]

[quoted text, click to view]

It not only did not originally have one, it does not currently have one.
And although some of the SQL Server functions do use 1 for True, that is not
a global convention, and you cannot use 1 as a predicate. So the following,
while perhaps valid if SQL Server truly had adopted the convention, is not
in reality valid TSQL:

SELECT 'ABC'
WHERE 1

If 1 really did evaluate to true (and if there were a boolean type), this
would be valid...


--
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--

[quoted text, click to view]

I just had a look for the original Ross Pressor/Mike Epprecht
thread, and it is gone! (Still available in some cached locations)
But it didn't look at the time as if either of those persons was
a troll. Although the Mike Epprecht person did describe VB
as 'brain dead', the rest of the message seemed sensible, and
there was no immediatly obvious reason to suggest that it would
be deleted.

Since you may have thought my original message was obscure,
I just take this opportunity to explain that SQL Server did not
originally have a Boolean data type, and has subsequently adopted
the C convention that True = 1. This convention derives from the
PDP machine language, which had a hardware instruction to
complement bits. For example: 0-> 1, and 1->0. In contrast,
the 80x86 family of computers has a Logical Not instruction
that complements words or bytes. Hence: 0 -> -1, -1 -> 0.

The VB convention of TRUE = -1 is logical for machines that have
TRUE = -1, and hence is logical for the 80x86 family of computers.

Going further back, the 80x86 machine language was designed to
support high level languages such as BASIC and Pascal, and BASIC
adopted the convention that True = complement(integer(float(1)))
because that was a common convention on existing machines.

regards
(david)




[quoted text, click to view]



[quoted text, click to view]



[quoted text, click to view]

[quoted text, click to view]

Well, it's kinda old, so it probably expired from your news server.

[quoted text, click to view]

Yeah, I didn't understand what you were driving at, and that's why I
labelled you as a troll. Sorry. "God developed C on a PDP" and the
implication that hardware-level memory partitioning is inherently evil,
both sounded to me like you were trying to stir up a holy war.

[quoted text, click to view]

Thanks for clearing up what you meant. I again apologize for branding you