Showing posts with label mytable. Show all posts
Showing posts with label mytable. Show all posts

Monday, March 26, 2012

parentheses in a check constraint

Can we use parentheses in a check constraint in MS-SQL-server DDL?

e.g. I'm having a problem with the following statement:

ALTER TABLE [dbo].[MyTable] ADD CONSTRAINT [CK_MyTable_TimesDataOK]
CHECK (([TimeOn] IS NULL AND [TimeOff] IS NULL)
OR
([ShiftCode] IS NOT NULL AND [TimeOn] IS NOT NULL AND [TimeOff] IS NOT
NULL));

The statement appears to run fine, but when I look at my table
definition afterwards, it appears that SQL-server ignored the
parentheses in my constraint; it shows the constraint expression as:
(([TimeOn] IS NULL AND [TimeOff] IS NULL OR [ShiftCode] IS NOT NULL AND
[TimeOn] IS NOT NULL AND [TimeOff] IS NOT NULL))

My intention is that if there's (non null) data in either of the columns
TimeOn or TimeOff is not null, all three of the columns TimeOn, TimeOff
and ShiftCode must have non null data.

OK, I realise I could enforce this by altering my table setup in other
ways. Right now I'm just trying to figure out if this I'm just up
against a difference between dialects of SQL in check constraints here.
Am I missing something obvious with parentheses?

BTW the DDL for the table I'm testing on:
CREATE TABLE [dbo].[MyTable](
[FNname] [nvarchar](50) NOT NULL,
[ShiftDate] [datetime] NOT NULL,
[ShiftCode] [nchar](2) NULL,
[TimeOn] [nchar](4) NULL,
[TimeOff] [nchar](4) NULL);Helen Wheels <helenwheelss@.yahoo.com.auwrote in
news:136mli9pi74bs63@.corp.supernews.com:

Quote:

Originally Posted by

Can we use parentheses in a check constraint in MS-SQL-server DDL?
>
e.g. I'm having a problem with the following statement:
>
ALTER TABLE [dbo].[MyTable] ADD CONSTRAINT [CK_MyTable_TimesDataOK]
CHECK (([TimeOn] IS NULL AND [TimeOff] IS NULL)
OR
([ShiftCode] IS NOT NULL AND [TimeOn] IS NOT NULL AND [TimeOff]
IS NOT
NULL));
>
The statement appears to run fine, but when I look at my table
definition afterwards, it appears that SQL-server ignored the
parentheses in my constraint; it shows the constraint expression as:
(([TimeOn] IS NULL AND [TimeOff] IS NULL OR [ShiftCode] IS NOT NULL
AND [TimeOn] IS NOT NULL AND [TimeOff] IS NOT NULL))
>
My intention is that if there's (non null) data in either of the
columns TimeOn or TimeOff is not null, all three of the columns
TimeOn, TimeOff and ShiftCode must have non null data.
>
OK, I realise I could enforce this by altering my table setup in other
ways. Right now I'm just trying to figure out if this I'm just up
against a difference between dialects of SQL in check constraints
here. Am I missing something obvious with parentheses?
>
BTW the DDL for the table I'm testing on:
CREATE TABLE [dbo].[MyTable](
[FNname] [nvarchar](50) NOT NULL,
[ShiftDate] [datetime] NOT NULL,
[ShiftCode] [nchar](2) NULL,
[TimeOn] [nchar](4) NULL,
[TimeOff] [nchar](4) NULL);
>


"When more than one logical operator is used in a statement, the AND
operators are evaluated first ..." (BOL) - your inner parentheses are
therefore unnecessary.|||Chris.Cheney wrote:

Quote:

Originally Posted by

Helen Wheels <helenwheelss@.yahoo.com.auwrote in
news:136mli9pi74bs63@.corp.supernews.com:
>
>

Quote:

Originally Posted by

>>Can we use parentheses in a check constraint in MS-SQL-server DDL?
>>
>>e.g. I'm having a problem with the following statement:
>>
>>ALTER TABLE [dbo].[MyTable] ADD CONSTRAINT [CK_MyTable_TimesDataOK]
>>CHECK (([TimeOn] IS NULL AND [TimeOff] IS NULL)
> OR
> ([ShiftCode] IS NOT NULL AND [TimeOn] IS NOT NULL AND [TimeOff]
> IS NOT
>>NULL));
>>
>>The statement appears to run fine, but when I look at my table
>>definition afterwards, it appears that SQL-server ignored the
>>parentheses in my constraint; it shows the constraint expression as:
>>(([TimeOn] IS NULL AND [TimeOff] IS NULL OR [ShiftCode] IS NOT NULL
>>AND [TimeOn] IS NOT NULL AND [TimeOff] IS NOT NULL))
>>
>>My intention is that if there's (non null) data in either of the
>>columns TimeOn or TimeOff is not null, all three of the columns
>>TimeOn, TimeOff and ShiftCode must have non null data.
>>
>>OK, I realise I could enforce this by altering my table setup in other
>>ways. Right now I'm just trying to figure out if this I'm just up
>>against a difference between dialects of SQL in check constraints
>>here. Am I missing something obvious with parentheses?
>>
>>BTW the DDL for the table I'm testing on:
>>CREATE TABLE [dbo].[MyTable](
> [FNname] [nvarchar](50) NOT NULL,
> [ShiftDate] [datetime] NOT NULL,
> [ShiftCode] [nchar](2) NULL,
> [TimeOn] [nchar](4) NULL,
> [TimeOff] [nchar](4) NULL);
>>


>
>
"When more than one logical operator is used in a statement, the AND
operators are evaluated first ..." (BOL) - your inner parentheses are
therefore unnecessary.


So they are. The constraint is working as expected, it just doesn't look
quite the way I'm used to reading it. Thanks.|||Helen Wheels (helenwheelss@.yahoo.com.au) writes:

Quote:

Originally Posted by

Can we use parentheses in a check constraint in MS-SQL-server DDL?
>
e.g. I'm having a problem with the following statement:
>
ALTER TABLE [dbo].[MyTable] ADD CONSTRAINT [CK_MyTable_TimesDataOK]
CHECK (([TimeOn] IS NULL AND [TimeOff] IS NULL)
OR
([ShiftCode] IS NOT NULL AND [TimeOn] IS NOT NULL AND [TimeOff] IS
NOT NULL));
>
The statement appears to run fine, but when I look at my table
definition afterwards, it appears that SQL-server ignored the
parentheses in my constraint; it shows the constraint expression as:
(([TimeOn] IS NULL AND [TimeOff] IS NULL OR [ShiftCode] IS NOT NULL AND
[TimeOn] IS NOT NULL AND [TimeOff] IS NOT NULL))


SQL Server does not store the constraint text as provided, but performs
some normalisations on it. One such normalisation is apparently to
remove superfluous parantheses. Your original constraint text and what
SQL Server saved, are equivalent. AND binds tighter than OR, so these
two are the same:

x AND y OR a AND b
(x ANY y) OR (a AND b)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Monday, February 20, 2012

Parameterized UDF in correlated subquery

Hello all,
I'm trying to run a query that looks like this:
UPDATE MyTable SET
ParsedField1 = (SELECT ParsedField1 FROM dbo.parseField(ot.FieldToParse)),
ParsedField2 = (SELECT ParsedField2 FROM dbo.parseField(ot.FieldToParse)),
ParsedField3 = (SELECT ParsedField3 FROM dbo.parseField(ot.FieldToParse)),
ParsedField4 = (SELECT ParsedField4 FROM dbo.parseField(ot.FieldToParse)),
FROM MyTable mt
INNER JOIN OtherTable ot ON mt.pid = ot.pid
<FieldtoParse> is a string that requires some fairly complicated logic to
parse so I encapsulated it in a UDF that returns a table resultset. However
,
using a parameterized UDF in a correlated subquery appears to be unsupported
.
It thinks it's a HINT! Can someone tell me if I'm right about that?
I have several other options I can use to get the same thing accomplished so
I'm not worried about that but this way would have been the cleanest.
Thanks for the help!
MikeWhy not to create a scalar function instead?
UPDATE MyTable SET
ParsedField1 = dbo.parseField(ot.FieldToParse, 1),
ParsedField2 = dbo.parseField(ot.FieldToParse, 2),
ParsedField3 = dbo.parseField(ot.FieldToParse, 3),
ParsedField4 = dbo.parseField(ot.FieldToParse, 4),
FROM MyTable mt
INNER JOIN OtherTable ot ON mt.pid = ot.pid
go
AMB
"Mike L" wrote:

> Hello all,
> I'm trying to run a query that looks like this:
> UPDATE MyTable SET
> ParsedField1 = (SELECT ParsedField1 FROM dbo.parseField(ot.FieldToParse)
),
> ParsedField2 = (SELECT ParsedField2 FROM dbo.parseField(ot.FieldToParse)
),
> ParsedField3 = (SELECT ParsedField3 FROM dbo.parseField(ot.FieldToParse)
),
> ParsedField4 = (SELECT ParsedField4 FROM dbo.parseField(ot.FieldToParse)
),
> FROM MyTable mt
> INNER JOIN OtherTable ot ON mt.pid = ot.pid
> <FieldtoParse> is a string that requires some fairly complicated logic to
> parse so I encapsulated it in a UDF that returns a table resultset. Howev
er,
> using a parameterized UDF in a correlated subquery appears to be unsupport
ed.
> It thinks it's a HINT! Can someone tell me if I'm right about that?
> I have several other options I can use to get the same thing accomplished
so
> I'm not worried about that but this way would have been the cleanest.
> Thanks for the help!
> Mike
>|||I can and did actually create one very similar to this. However, my
question is more academic. I haven't found anything saying this is
prohibited but it doesn't appear to work. I was just wondering why or if
there's a syntax "trick" you have to use to get it to work.
Thanks for the reply though!
Mike
"Alejandro Mesa" wrote:
> Why not to create a scalar function instead?
> UPDATE MyTable SET
> ParsedField1 = dbo.parseField(ot.FieldToParse, 1),
> ParsedField2 = dbo.parseField(ot.FieldToParse, 2),
> ParsedField3 = dbo.parseField(ot.FieldToParse, 3),
> ParsedField4 = dbo.parseField(ot.FieldToParse, 4),
> FROM MyTable mt
> INNER JOIN OtherTable ot ON mt.pid = ot.pid
> go
>
> AMB
> "Mike L" wrote:
>|||Mike
Can you show us an UDF? I'm pretty sure that Alejandro answers your
question.
"Mike L" <MikeL@.discussions.microsoft.com> wrote in message
news:230EE401-C561-45F6-8396-0F9E9E071A0D@.microsoft.com...
> I can and did actually create one very similar to this. However, my
> question is more academic. I haven't found anything saying this is
> prohibited but it doesn't appear to work. I was just wondering why or if
> there's a syntax "trick" you have to use to get it to work.
> Thanks for the reply though!
> Mike
> "Alejandro Mesa" wrote:
>