Re: Inconsistent Double Notifications
it is interesting (sad eh) that the notify function is designed to
return multiple rows per subscription, (see recent post by Shyam) and
maybe that some kinds of join can cause confusion in this respect.
I notice on Ravens caseManagement example that the TransactionId on the
last join is not a final notification field. it would be useful to see
this in there as it would confirm if any of the duplicates are in fact
coming from confusion in the join.
I would also put a datestamp on every incoming event and carry this
thru to the notification so that i know precisely which event record
was match into what notification. This avoid ugly confusion when
tracing these problems particularly when there are few natural keys.
It may be that the NSFoo problem is similar. Although the rule is a bit
strange with no subscriber join in it. I have not seen the design for
NSnotify but I think this multiple row thing could be at the bottom of
It would be nice if Shyam , who knows its inner workings, could comment
on this possibility
Get your notification services implementation going in minutes not