We’ve been developing code on Windows and Unix for quite some time, but most of the distributed component work we’ve been involved in has been done using COM. That’s changing now as clients have more requirements for Unix based component solutions. We’re currently evaluating CORBA ORBs and learning how the CORBA way of doing things differs from the COM way.
The first difference that we came across was the way that CORBA servers deal with object lifetime issues.
COM+ applications can be complex to configure and there’s no standard way to save that configuration in a form that can be placed under version control. Luckily the COM+ Catalog is accessible by a set of completely scriptable COM objects. These scripts take advantage of this to provide some functionality that should really come as standard.
Scripting the COM+ Catalog
COM+ applications can be complex to configure. This complexity increases as you use more COM+ services.
If you are going to use the client cursor engine then often it’s a good idea to disconnect your recordset…
Disconnected Recordsets
The normal procedure for using the Client Cursor Engine is to open your recordset with client side cursors and then disconnect it from the data source. This causes the CCE to pull all of your data out of the data source and effectively marshal it by value to your client.
How to package lots of standard functionality into a CListBox derived class.
The problem
Several times now I’ve found the need for a pair of list boxes that are linked. Items can appear in either of the list boxes, but not in both. Items can be moved between list boxes, and have processes performed on them. Their order within the list boxes can often be shuffled.
The first time I ended up with all of the code to do this spread throughout the message handlers of the enclosing dialog box.
Localise design decisions by writing key application functionality as pluggable COM objects. When the requirements change you just write a new plug in…
Introduction
Sometimes it’s difficult to see the wood for the trees. You know that using COM is good, but how can you use it? How do you write an app that uses COM? How do you get from IApe and all the text book examples to something in the real world?
It’s rare that code can be viewed as a black box for reuse. If you include design choices and dependencies as valid parts of the code’s interface then it’s easier to explain why reusing nontrivial code is often harder than writing it from scratch.
One of the problems that I find when I’m trying to reuse some code is that even if the code is documented well, or written in a style where little documentation is needed, it can rarely be used as a black box.
Making the ADO Client Cursor Engine believe that your rowset is updateable involves jumping through a few extra hoops…
Client Cursor Engine Updates
It turns out that supporting updates through the client cursor engine is relatively easy. Discovering that it’s relatively easy was extremely difficult. An article that was recently added to the MSDN gives complete and full information on what a rowset needs to support for updates via the CCE to be possible.
The ATL OLE DB Provider templates only seem to support read-only rowsets, and making them support updating of data isn’t as easy as you’d expect!
Cursors everywhere
First it’s worth clearing up some confusion about client and server side cursors and our rowset. Normally selecting either client or server side cursors is a simple choice between network traffic and local storage. Server side cursors are physically located with the data and in the case of most OLE DB providers that’s probably on the far end of a network connection to your database server.
Adding bookmark functionality is relatively easy and it enables our ADO recordset to be used with a greater number of data bound controls.
IRowsetLocate and bookmarks
To support some of the more demanding data bound controls we need to support bookmarks. The proxy rowset that we developed in the last article already has some support for bookmarks built in, but the rowset itself doesn’t expose IRowsetLocate, or the bookmark related properties, so the bookmark functionality can’t be used by consumers.
The ATL OLE DB Provider templates appear to rely on the fact that your data is kept in a simple array, but that’s not really the case at all!
Implementing a custom OLE DB rowset
This article continues from where we left off in the previous article. We have all of the framework in place to provide ADO recordset interfaces on our simple data object. All we need to do now is replace the wizard-generated OLE DB rowset object with one that allows us to access our object’s data.
