@PaulWhite I use Hugo - same as Kendra. Her blog post motivated me to start, and I've used the same theme as well. I have several custom integrations "borrowed" from the community.
@HannahVernon Is there anything we can do about that particular poster?They seem to have a penchant for doing some mild reading on a particular subject, then blasting out a ton of basic questions on it, most of which could be satisfied with reading the docs or "trying it out".
@Charlieface we have communicated our distaste for their antics in the past. I just sent them another message about not over commenting.
@Charlieface I believe the odbc functions are subject to the same rules as other date functions; in other words they are sensitive to localizations such as set dateformat. Perhaps that should be asked on the main site.
@Zikato I learn something new every day. And it seems like every day, I make a totally wrong assumption. Perhaps that's the thing I'll learn today, to not make assumptions. Probably not today, but maybe.
> The single-threaded CPU performance of your processor is usually the final performance bottleneck in a well-tuned system that does not have any other substantial bottlenecks. - Is the CPU Important for SQL Server?
Based on that, it seems like the answer to the blog title is "no" 😀
I get that everyone has their pet peeves, and one of Glenn's is when people don't know their CPU's special name. But just because something bugs you doesn't mean it's important.
one of my pet peeves is when people don't know their CPUs are offline because their 20 person dba team installed the cal bits on every server under the roof
that's probably more important than a cumulative gigahert
lol, not really - I needed to answer a question from 2012; I already had SQL Server 2000 installed, but wanted to see if the problem had persisted into 2005. It had not as it turns out.
10 year old question answered on Internet
Actually I wasn't so concerned about answering the question as i was about removing the comments on the question.
Anyone got any idea on this one? How is it possible for a foreign-key cascaded delete to have a CONVERT_IMPLICIT(bigint in the join between parent table spool and the child table? I just can't see how it's possible to induce a conversion, because otherwise the foreign key wouldn't be allowed.
I have these two below tables on which I am performing delete followed by an insert but intermittently deadlocks are being encountered.
Schedule.Assignments (Parent table)
[Schedule.Assignments (Parent table)]
Schedule.Schedules (Child table)
[Schedule.Schedules (Child table)]
Intermittently tw...
@HannahVernon But how is that possible? If you actually did look, you would see the conversion is part of the foreign key lookup, which happens automatically, and must by definition have the same data type. The actual lookup on the parent table as written in the main SQL does not have an implicit conversion.