The only candidate for clustered index I can see for such tables is IDENTITY column.

If you use pagination for displaying results on front end it would be a good idea...

So, you actually don't do joins.

You don't use relational database functionality and use database tables as set of flat files.

That's what I suspected when you described your tests.

Yes, set of...

Sorry to disappoint you but you do destroy the index.

Check the execution plan. You'll see both CONVERT and clustered index scan (which is the same as table scan) there.

Can you post an example of your join query?

Even in small notebook it's faster to find a record if it has A-Z index (which is actually clustered index).

I don't think you should split messages in SQL Server.

Module sending SMS should take care of it.

Otherwise recipient will receive many separate messages instead of multiple parts of the...

If you compare values with different data types you do conversion. If you don't see it it does not mean it's not there. It's just implicit, which is the worst...

Because it connects to SQL Server using connection string.

Did your mom tell you not to trust strangers?

> Here, i wanted to get the data having backups and no backups with in last day.

You mean having backups but not within last day?

It's easy. Just remove IS NULL...

> But for a deeper thought we have quite a # of gurus here like Sergie and Jeff.

Guru's suck.

Would not say about every one, but pretty sure about the one...

What's exactly gives you a trouble with it?

Jeff, "AND bs.Backup_Finish_Date > GETDATE()-1" in WHERE clause changes RIGHT OUTER JOIN to INNER JOIN.

Probably what was originally requested supposed to look like this:

SELECT sd.Name, MAX(bs.Backup_Finish_Date) Last_Backup

FROM...

I believe if you'll split by words it's not gonna have chunks more than 150 characters.

You may use UDF posted here:

http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=8&messageid=310562&p=4

to split any string into words.

P.S. "Array" means "Table" in...

Yes, I'm pretty sure.

Calculation based on FLOAT gives you 17 precise digits, calculation based on DECIMAL brings you 14 digits, all precise.

Comparing those numbers I conclude that 17 > 14...

Actually you are limiting to 100 records from Users, not from Orders.

So, what you get is all orders for 100 selected users.