Hi Chase..

I've had success using OPENROWSET to do this work.  Check out this blog entry.

Hope this helps..

To do this in schema, you'd need two columns (FKtoTableB and FKtoTableC).  If each column was NULLable, you could then write a view that uses the COALESCE function to snag...

Is the client SQL savvy?

Are they aware of the XML enahncements in SQL Server?

You've perhaps got an opportunity to educate them..  but if they're resistant, I suppose you should give...

This looks to me like an ideal candidate for using XML to pass your parameters.

I'm currently on vacation and away from my archives, but if this is of interest early...

You should be able to write a version of this query using the new ROW_NUMBER intrinsic as well..

Hi..

I'm away from my office (and my archives) at the moment, so it will be next week before I can get this to you.

If you look through BOL, you'll find...

As a best practice, I would recommend staying away from "old style" joins (table names separated by commas).  In certain scenarios, they can produce ambiguous results.

Stick with the "new style"...

Hi..

Without a full repro, it's difficult to draw a firm conclusion about your issue.  At first blush, though, it sounds as though it might be a collation issue in the...

In this instance, then, I would use SQL Server's timestamp datatype.

I'm a litle confused about your "binary value" statement; timestamps are far from binary.  So I may still not be giving...

Hello..

I would suggest a datetime value, set to the current UTC time (GETUTCDATE()).

Hope this helps!

I'm glad this worked for you!  FYI, you can also handle the sequencing issues within the syntax of the CTE thusly:

declare

@temp table

(

Hello Chandrika..

This is a job for "the OPENROWSET trick," which you can find on my blog here.  This solution will work for either SQL Server 2000 or SQL Server...

Hello Grant..

If your project calls for manipulation of XML or long strings, you can make a reasonable statement that your productivity will be higher under SQL 2005 than SQL 2000. ...