Oh yeah, I've seen that before. It comes from several sources. It could be that you're dealing with table variables or multi-statement table valued user defined functions. Because they don't...

Just no way to say without the query and the execution plan to understand what's happening and why.

I'm with Gianluca on this. It's hard to tell you what the problem is without actual error messages.

Do you have a backup available? It sounds like you might need to...

Which event did you use? Showplan XML Statistics Profile will capture actual plans. But, it has an extremely high overhead. Because trace has such lousy filtering, I don't recommend you...

Some other issues include the fact that while the indexes on in-memory tables have statistics, you can't see the statistics information using DBCC SHOW_STATISTICS. Further, because of this, while the...

From the slides on the precon I did last week at Summit, this is just a list of table restrictions:

Restrictions

No LOB

No CLR

No user defined types

No VARIANT

No ROWVERSION

No foreign keys

Must have...

No. No, no, no. Don't do that. Everything just doesn't belong within the in-memory sphere. If you're not experiencing significant slow downs due to latch waits, you really shouldn't even...

No, there is no way to "push" a table to be in-memory. You must create an in-memory table following all the restrictions and then move the data into that table....

In addition to the good suggestions so far, you should also factor in the number of transactions each supports. The recovery process of the restore operation when transactions are rolled...

Thank you for the kind words.

I don't know that I would sweat adding the additional 8 bytes. It's not that much. Yes. it'll be a little wider, but if...

You have to make a determination for hardware through a whole slew of factors. How much data do you anticipate? How many users will there be? How many transactions will...

Did you try connecting with the dedicated admin connection (DAC)? I've seen that work in similar circumstances. And yeah, I think your devs might be out to lunch on this...

I'd go right by 2012 and use 2014. The licensing costs are about the same, and the number of enhancements to 2012 functionality around things like columnstore, statistics, statistics maintenance,...

It's a little more complex than that. You also have to take into account the logical, or business, identifier for each row. This is sometimes referred to as the natural...

And, in the event of failover, async means no guarantee of intact data.