SQL 2005 vs SQL 2000: Where clause Short-Circuiting?

Hello all, this is my first post, and I think I've found something interesting between sql 2005 and 2000. Thanks in advance for any help you can provide.

I am attempting to migrate a system from SQL 2000(v 8.00.2039 - Enterprise Edition) to SQL 2005 (v9.0.2047 - Standard Edition ), and a few of my most complex queries are generating errors. I was able to isolate the problem to a fairly simple query that works in SQL 2000, but generates an error in SQL 2005.

I believe that the problem has something to do with how short-circuiting is handled in the WHERE clause. I'm not sure if short-circuiting is really going on when these statements are parsed, but it seems to describe the situation well.

To replicate the problem, first create the following table and fill it with values:

----------------------------------------------
create table OrgView (ORGNAME varchar(100), QID int, ANSWER varchar(100))

insert into orgview (orgname, qid, answer) values('org1', 120, '1')
insert into orgview (orgname, qid, answer) values('org2', 94, '2006-06-06')
insert into orgview (orgname, qid, answer) values('org3', 98, 'free kevin')
----------------------------------------------

The second value (org2) contains a date, but the rest do not.
Under both systems, the following contrived query works fine:

SELECT orgname FROM OrgView
WHERE (QID = 94
AND CONVERT(DATETIME, Answer) = '2006-06-06')

It would seem, that when QID = 94, the expression short circuits, and the CONVERT statement doesn't run. This is good, because the CONVERT statement would throw an error whenever 'Answer' doesn't contain a date.
However, if modify the query by adding an OR to the end like this:

SELECT orgname FROM OrgView
WHERE (QID = 94
AND CONVERT(DATETIME, Answer) = '2006-06-06')
or QID=98

then the query fails on SQL 2005 with a 'Conversion failed when converting datetime from character string.' error.
On SQL 2000, the short circuiting works fine, and the above query returns 'org2' and 'org3'.
I know shortcircuiting may not be the best way to describe the set calculus going on in the background, but can anyone explain what is going on here Is there any way to make SQL 2005 work like SQL 2000 in this specific case

Thanks,

-Adam