MS EntLib June 2005 DAAB & Oracle Stored Procedures

Going back today to see whats what in calling Oracle stored procedures w/wo ref cursors using the DAAB, and if my understanding is correct, then in general all [Oracle] stored procs, must have an output ref cursor defined called cur_OUT.

The exception as far as I can see is as follows;

You have a stored proc which returns 1 or more ref cursors, and, you add those in/out ref cursor parameters to the command wrapper in your code (which sets the isRefCursorAdded field of the CommandWrapper object, which in turn is referenced by the XXXDatabase object’s PrepareCWRefCursor method)

While this kind of makes sense, given that Oracle ref cursor parameters have to be defined as OracleType.RefCursor as opposed to SqlType.Cursor, and also given that one goal of the DABB is data provider abstraction – the solution seems a bit dumb.

Thinking off the top of my head, maybe a better solution would have been be to ask the command wrapper to add a refcursor type parameter [using say, a specific method call], which in the case of the SqlDatabase version would do nothing, but would be implemented correctly in the Oracle and ODP versions. Of course, one of the nice things about the ENTLIB is that you get the source, so can be modified to suit, which is how I added XXXDatabase support for the Oracle ODP data provider.

A trade off of this kind of solution is that if your code is generic (you aren’t branching based on the type of XXXDatabase object), you will have extra calls to this “AddRefCursorParameter” method for each ref cursor, which in fact mean nothing (and would do nothing) in the case of a SQL implementation – which may be confusing.

I think I’ll try this out, and post it up here if it works out nicely.

Update 1st Dec 2006:-

Looks like I wasn’t the first to think of this. Rob Edwards posted here proposing just the same thing.
[http://oneprogrammer.blogspot.com/2005/04/writeup-for-oracle-changes.html].

Digital Rights Management

This thing just drives me crazy, you can buy a licence to listen to some music but only;

a). on your PC

b). but also on your iPod if you happen to have (or go buy) an iPod

Now your music industry apparatchics will drone on about defending the rights of music owners to be paid for their work, and quite right to – thats why I pay actual cash money for it.

But you know what, if they’re going to treat me like a criminal;

a). Fuck you I’m off to buy an actual CD and I’ll rip the tracks off that

b). Fuck you, I’m not going to buy your music

c). I’ll buy your music then I’ll find a piece of software to write the music to a non-protected form

So music industry big-twits, where does this leave you?

Nowhere is where, you haven’t stopped copyright theft (because if I can do the above, so can your average crim’), and more important you’ve mightily pissed off an actual paying customer.

Services without Components (SWC) and ServiceConfig Bug??

So I’m developing a serviced component in C#, and this component is intended to model mixed mode transactional capability, in that some methods will be transactional and some not. Therefore the component is configured in COM+ as Transactions: Disabled.

The transactional methods will use SWC ServiceConfig to create a transactional context in which to perform work.

The problem I’ve found concerns use of the Inheritance property;

- If I set the property to Ignore, a new context is created which is not transactional (ContextUtil.IsInTransaction = false) and security is not enabled in the new context (which I would expect).

- If I set the property to Inherit, a new context is created which again is not transactional (ContextUtil.IsInTransaction = false) but this time security is enabled in the new context (fair enough, new context inherits this from existing context).

- If I don’t set the property at all, a new context is created which is transactional (ContextUtil.IsInTransaction = true) and security is not enabled in the new context (not sure what to expect at this point since I’ve not specified Ignore or Inherit).

The documentation states that this property defaults to “Inherit“, from my experience this doesn’t seem to be bourne out – is it a bug.

I’ve trawled the internet and not found anything, anyone else come across this??

My environment: XP Pro SP2, VS.NET 2003 SP1, .NET v1.1.4322