| Author |
Topic  |
|
|
AskSQLTeam
Ask SQLTeam Question
USA
0 Posts |
|
|
aiken
Aged Yak Warrior
USA
525 Posts |
Posted - 09/01/2002 : 01:30:54
|
I was involved in the beta of this, and I'm still not sure what I think.
One of the things we all love about SQL server is that it makes sense; it's very rare to find an issue in SQL server where you would say "yes, that would work great, but they seriously screwed up the schemas and locking" (other than SQL Mail, which is an issue unto itself).
However, SQL NS is frustrating. It's *almost* right, and will no doubt be fixed in the next rev (or version 3). If you've worked with exchange, you know the issues I'm talking about -- shortcuts, inconsistancies, and generally sub-par schema designs (at least, if you're used to MSSQL 2000).
I would definitely encourage folks to try it, but for the time being we are staying with out homebrew notification system, which has its own serious flaws. Still, it mostly works, and so far I haven't seen any incentive to move from our partly broken implementation to MS's.
Cheers -b
|
 |
|
|
setbasedisthetruepath
Used SQL Salesman
USA
992 Posts |
Posted - 09/01/2002 : 09:00:05
|
Aiken, How would you compare SQL NS to, say, a MSFT Operations Manager - based notification architecture?
Jonathan {0} |
 |
|
|
aiken
Aged Yak Warrior
USA
525 Posts |
Posted - 09/01/2002 : 14:51:23
|
They're really pretty different -- notification services is intended to manage messaging / notification for users of an appliction. For instance, it could easily replace the "subscribe" functions of this snitz message board. Right now, when anyone posts a new message, during the post process Snitz looks up whether anyone is subscribed to the entire board, category, forum, or topic that the post is in, and then generates emails to those people. SQL NS is an application framework that would move that functionality right into the DB, and transparently add support for other notification types (pager, SMS messages, etc).
Cheers -b
|
 |
|
| |
Topic  |
|
|
|