Just a reminder: I was trying to create a temporary table in SQLServer 2k8 using a user-defined data type, a bit like:
use MyDB;
create table #myTempTable
(
MyField udt.MyType_t not null
)
but hit
Could not find data type udt.MyType_t
This is because the type is only defined in my database MyDB – it’s not defined in TEMPDB. When you try to use it when creating a temporary table the database can’t find it.
The workaround is to use the underlying data type instead.
I had a fun five minutes today trying to express a wait on three WaitHandles X, Y and Z in which I want both of X and Y to be signalled, but have Z as an early escape. It’s soon clear that you can’t express:
(X && Y) || Z
With WaitAll and WaitOne, e.g. as
WaitHandle.WaitAll{ X, Y } || Z.WaitOne
because WaitAll blocks.
Thanks to the fact that boolean operations are distributive I can recompose (X && Y) || Z as
(X || Z) && (Y || Z)
and apply that structure in this case as
WaitHandle.WaitAny{ X, Z } && WaitHandle.WaitAny{ Y, Z }
with the proviso that the state of Z is unchanged by the Wait – for example, as long as Z does not autoreset.
My particular example was in managing a task workflow – the kind of thing that’s (almost certainly) made redundant by the TPL in .NET 4+. In my case, X and Y are a throttle on in-flight tasks, and a turnstile that admits workers when tasks are newly runnable. Z is an early escape in case of shutdown or exception.
I’m hoping that some clever bod will spot this and point out there’s a perfectly natural and convenient way of expressing this more simply.
I don’t need to create custom configuration sections for .NET apps very often; whenever I do, it seems like an awkward process.
I hit a new problem recently; only a small one, but sufficiently frustrating that I need to commit it to memory. I was mixing up the two distinct methods for creating the configuration: programmatic, and declarative (or attributed).
The symptom was a “key has already been added” exception when loading a new application’s configuration. The exception was thrown by configuration elements added to a custom ConfigurationElementCollection.
The error seemed clear: I’d already added a config item with this key. So how do I define the key for an item? Figuring it’d be easy I leant on Intellisense, found the IsKey attribute and thought – great! I can define the properties that make up the key. Happily, I added key properties to my derived ConfigurationElement, suitably attributed.
Daft.
It didn’t work, and it took me a little while to figure out what was going on. I’d forgotten that the ConfigurationElementCollection acts as a factory of sorts – and is also given the responsibility of generating the key. I’d filled out some simple placeholder code to generate an element key there which clearly wasn’t up to the task.
It was only after that, when I looked more deeply into the ConfigurationElementCollection that I realised I’d been mixing mechanisms for expressing the custom configuration. The IsKey attribute was irrelevant, as the mechanism I was using to generate the collection was programmatic.
So, multiple lessons learned: don’t lean on Intellisense without reading the docs; think about the structure of your data, even if it’s a configuration element; and don’t add placeholder code for functions like key generation.
