formula column

Hi,
I would like to create a calculated column using the formula
section for a table. I am having some trouble doing this.

The table's name is ReportParameter. The calculated column's name is
tbcalculatedcolumn and tb1 and tb2 are boolean columns in the table.
I would like to use an If then statement such as the following (in
psuedo code):

If tb1 = 1 then tbcalculatedcolumn = 1
Elseif tb2 = 1 then tbcalculatedcolumn = 2
Endif

Thanks for the help,
BillHi

Maybe something like:

CREATE TABLE MyTable ( tb1 bit, tb2 bit, tbcalculatedcolumn AS CASE WHEN
tb1 = 1 then 1
WHEN tb2 = 1 then 2
END )

INSERT INTO MyTable ( tb1, tb2 ) VALUES ( 1,1 )
INSERT INTO MyTable ( tb1, tb2 ) VALUES ( 1,0 )
INSERT INTO MyTable ( tb1, tb2 ) VALUES ( 0,1 )

SELECT * FROM MyTable
/*
tb1 tb2 tbcalculatedcolumn
-- -- ------
1 1 1
1 0 1
0 1 2
*/

John
"Billy Cormic" <billy_cormic@.hotmail.com> wrote in message
news:dd2f7565.0310010526.3ce4be47@.posting.google.c om...
> Hi,
> I would like to create a calculated column using the formula
> section for a table. I am having some trouble doing this.
> The table's name is ReportParameter. The calculated column's name is
> tbcalculatedcolumn and tb1 and tb2 are boolean columns in the table.
> I would like to use an If then statement such as the following (in
> psuedo code):
> If tb1 = 1 then tbcalculatedcolumn = 1
> Elseif tb2 = 1 then tbcalculatedcolumn = 2
> Endif
> Thanks for the help,
> Bill|||> I would like to create a calculated column using the formula
Why? Why not just put a CASE expression in a query or view rather than
create an extra redundant column.

> tbcalculatedcolumn and tb1 and tb2 are boolean columns in the table.
There is no Boolean data type in SQLServer. You mean a numeric column
(presumably BIT).

--
David Portas
----
Please reply only to the newsgroup
--

"Billy Cormic" <billy_cormic@.hotmail.com> wrote in message
news:dd2f7565.0310010526.3ce4be47@.posting.google.c om...
> Hi,
> I would like to create a calculated column using the formula
> section for a table. I am having some trouble doing this.
> The table's name is ReportParameter. The calculated column's name is
> tbcalculatedcolumn and tb1 and tb2 are boolean columns in the table.
> I would like to use an If then statement such as the following (in
> psuedo code):
> If tb1 = 1 then tbcalculatedcolumn = 1
> Elseif tb2 = 1 then tbcalculatedcolumn = 2
> Endif
> Thanks for the help,
> Bill|||Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in
your schema are. Sample data is also a good ideas, along with clear
specifications.

>> The table's name is ReportParameter. <<

That is not a table name; a table is an entity or a relationship. It
is also too vague to be a data element. You need to read a book about
database design.

>> The calculated column's name is "tbcalculatedcolumn" ...<<

Please tell me that "tbl-" is not a silly redundant prefix; and there
is always a better name than "calculated_column" for a calculated
column -- what extactly did you you compute? Interest? discounts? To
be is to be something in particular; to be nothing in particular is to
be nothing.

>> and tb1 and tb2 are boolean columns in the table. <<

There are no BOOLEAN variables in SQL; it would destroy the 3VL. Look
up the CASE expression in any pf the books on SQL you clearly have
never read.|||> There are no BOOLEAN variables in SQL; it would destroy the 3VL.

Aren't Booleans defined in SQL99?|||Yes. Joe goes into denial when confronted with SQL99 ;-)

--
David Portas
----
Please reply only to the newsgroup
--

"Christian Maslen" <christian.maslen@.techie.com> wrote in message
news:b9c8cfba.0310021514.11d51a@.posting.google.com ...
> > There are no BOOLEAN variables in SQL; it would destroy the 3VL.
> Aren't Booleans defined in SQL99?|||>> Joe goes into denial when confronted with SQL99 <<

So does everyone else who worked on the draft documents :)

They had to re-define the foundation to get them into SQL-99 and this
is oneof many reasons nobody is gallopping to SQL-99. The US
government requires SQL-92 and refers to it as "a standard in
progress" in their bid forms.

The problem is that a data type in SQL must be NULL-able; a NULL
doesnto have a data type itself, but holds a place for a value which
may or may not be determined later.

1) The fundamental rule of a NULL is that it propagates.

2) The fundamental rule of 3VL is that your have TRUE, FALSE and
UNKNOWN as the only possible values.

These fundamentals don't go together if you can have a column with a
3VL datatype. The "solution" was to make NULL = UNKNOWN but only in a
BOOLEAN column and then worry about null propagation. This screws up
3VL operators in some pretty awful ways that can drive an SQL engine
nuts:

FALSE OR UNKNOWN = UNKNOWN -- definition of OR
FALSE OR NULL = NULL = UNKNOWN -- null propagation
TRUE OR UNKNOWN = TRUE -- definition of OR
TRUE OR NULL = NULL = UNKNOWN -- null propagation

likewise,

TRUE AND UNKNOWN = UNKNOWN -- definition of AND
TRUE AND NULL = NULL = UNKNOWN -- null propagation
FALSE AND UNKNOWN = FALSE -- definition of AND
FALSE AND NULL = NULL = UNKNOWN -- null propagation