2014.10.26 Programmer's Notes

Next up is the unlinking of objects prior to a deletion.  Identifying the affected records
is a select before any of the dependencies are cleared or deleted:

SELECT
	prvbase.classcode as prvclasscode,
	this.prevone as prevone,
	this.prevtwo as prevtwo,
	nxtbase.classcode as nxtclasscode,
	this.nextone as nextone,
	this.nexttwo as nexttwo
FROM
	chaintable this
	outer join chaintable prvchain on
		this.prevone = prvchain.pkeyone
		and this.prevtwo = prvchain.pkeytwo
	outer join supertable prvbase on
		prvchain.pkeyone = prvbase.pkeyone
		and prvchain.pkeytwo = prvbase.pkeytwo
	outer join chaintable nxtchain on
		this.nextone = nxtchain.pkeyone
		and this.nexttwo = nxtchain.pkeytwo
	outer join chaintable nxtbase on
		nxtchain.pkeyone = nxtbase.pkeyone
		and nxtchain.pkeytwo = nxtbase.pkeytwo

If there is no classcode, then there is no need
for the outer joins because we don't need to
retrieve the classcodes for use in auding the changes.

Updating the objects gets a little bit hairy
but is manageable.  I'd thought I'd have a problem
correlating the columns to be updated, but then I
realized I'm updating the next link of the previous
object to the next link of this object, so the
column names correlate and are predictable.  Which is
a relief, because for an hour or so there I was dreading
having to move the update code to a sub-stored-proc in
order to alias the column names predictably.

The update of the prev object in the sp_create() code
will be used as a template for the updates of the prev
and next linked objects.  Note that these updates have
to be performed *before* any clearing of references or
deletion of sub-objects, much less the deletion of this
object.  It's not safe to delete anything until the links
are updated to unbind this object from the chain.