Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications. It is very hard to debug code when you do not let us
see it.
What you did post looks screwed up. Where is the date of these events?
Your data elements are also wrong according to IS rules. What
kind of status? Why is an event_id needed at all (surely you did not
use an IDENTITY column!!)? etc.
Here is a guess at a correct DDL:
CREATE TABLE Events
(event_name CHAR(10) NT NULL
CHECK (event_name IN ()),
event_date DATETIME DEFAULT CURRENT_TIMESTAMP NT NULL,
to be the entire daet duration,
event_status CHAR(1) DEFAULT 'P' NT NULL
CHECK (event_status IN ('P', 'R', 'C')),
PRIMARY KEY (event_name, event_date));
>I am trying to write a query that will return me all events that don't [have] status [both] R or C <<
That leaves only 'P' according ot your vague narrative.
SELECT event_name, @my_event_date
FRM Events
WHERE event_date = @my_event_date
AND event_status = 'P';
did you mean that events that lack either 'R' or 'C' codes, but have
'P'?
SELECT event_name, @my_event_date
FRM Events
WHERE event_date = @my_event_date
GRUP BY event_name
HAVING ( MIN(event_status <'C')
R MAX(event_status <'R'))
-- AND ****(*) = 2
The ****(*) is for the ('P', 'R') and ('C', 'P') cases. You did not
say what to do about ('C'), ('R', 'C') and the empty case. You can
modify this easily, tho.
It should run about 10 to 100 times faster than your cursor on large
data sets.
>I know how to do it with cursor logic, and using various temp tables <<
Why? You should never write a cursor when a query can do the job.
That is about 99.98% of the time.
>I also wanted to check that the three statuses that it has are P, R, and C. <<
That makes no sense; if it is missing 'R' or 'C', then is cannot have
all three. You use a CHECK() constraitn to limit the possible values.