When is it NOT advisible to use an ORM like Linq-to-SQL / Entity Framework for a program?

Question

Possible Duplicate:
Are there good reasons not to use an ORM?

I've just started learning what an ORM is and how it can help me save time and make applications more secure. Since this is new to me, after using ugly SqlCommands and whatnot in my C# code, this is the best thing since sliced bread.

However since I'm new I might not be aware of the pitfalls they bring.

When should I NOT use an ORM?

EDIT: Why are three people voting to close this perfectly legal question? There must be some concrete reasons why you would not use an ORM.

Answer 1

I found out that there are situations in which, for performance-critical code, the generated SQL statements are not optimal. I think that this is a typical use-case when you should not use an ORM.

You should always check what the generated SQL looks like and analyze the impact of changing some calls with custom SQL in order to improve performance.

Answer 2

Bulk operations are best done as close to the SQL as you can get -- inserting 1000 rows using an ORM is likely to be less performant than creating a large SQL string and sending it down to the server.

Answer 3

This is like when to use assembler or C#. When you need to perform very specific operations and/or optimize your code, perhaps you will have to go down some levels. If you don't have these specials needs you will implement faster and more easily using higher level libraries-wrappers-languages or whatever.