Yep, sounds good.  Thanks.

The problem from this solution is that all fields need to be the same type, i.e. varchar.

I've decided to go with a single Event table with NULLs.  Anything else would...

Thank you for your solution.  From first glance, that seems to be one way to go and would avoid NULLs.  I'll have a closer look today and see what happens.

Thanks.

I've just been told to have a single Events table and jam all the different event fields into a single varchar column, with a separator such as a semi-colon...

They can't...

One thing I should mention is that it is HIGHLY unlikely that another event type would ever be added.  I simply used the "events" tables as an example.  But the...

Yes, but each event has different information.  So if I combine all 3, then there would be NULLs in fields that dont apply to those events.  This breaks normalisation rules.

Thanks everyone for their feedback.  I've managed to convince the DBA's to make our TEST and PROD environments identical (which is how they should have been in the first place)......

Thanks for the info.

yes, I agree, and have been saying that for a while now.  But it is out of my control...

I agree, maybe not DEV, but TEST should be...

Thanks.

How about stored procedures then?  I can do it using EXEC sp, but I need to call it inside a select...

Thanks for the info guys.

One thing though, I did not get any performance boost as expected.

Know why this is the case?

Or am I on another planet? 😉

If I could find what you're referring to, then I wouldn't post my message.  Obviously I did not find it.

Thanks for the lecture anyway.

We're actually using SQL Server 2000, so shouldn't the WHERE clause work?

We are using Windows Server 2003 though, but I don't think that makes any difference... hopefully.

Yeah I've got the subquery equivalent but was just curious to know why it doesn't work.  It works on all our dev boxes, but not in production...

Thanks for the info,...