Multi-client enviroment, 1 database

I was thinking of a UDP broadcast message, need to figure out how the infrastructure here limits ports (or not), but yes. Many different ways to skin a cat. Might just go the MSMQ route since I've worked with that before and I'm trying to convine the guys in charge of integration to use MSMQ/eConnect exclusively and kick Scribe out on the curb like the bad ho they are.
 
Couch DB is WAY WAY to bloated for something as simple for what OP wants. You're talking about 500mb install for a message channel.
Well from what I understood he is looking for a "message channel" sitting on top of an SQL Server DB. Replace DB + message channel + glue between the two with something that has it all rolled together and is fully scalable. CouchDB may very well be overkill in this case, but it is something to consider if you are re-developing the system anyway.
 
Well from what I understood he is looking for a "message channel" sitting on top of an SQL Server DB. Replace DB + message channel + glue between the two with something that has it all rolled together and is fully scalable. CouchDB may very well be overkill in this case, but it is something to consider if you are re-developing the system anyway.

You do know that CouchDB/NoSQL is not a relational database right?
 
Gawd. OP can respond im just in awe at that remark.

Fully aware thanks. Does it need to be one?

lol, yes it has to be one because data integrity is very important to us

Are you sure MS SQL cant do this? I would very suprised to hear they cant.

I know Oracle does :
http://docs.oracle.com/cd/B19306_01/appdev.102/b14251/adfns_dcn.htm

Working off the wording I googled and found "SqlDependency objects". Will have a look at that, thanks

Omg. MS Access. Run. No wonder you hate IT :)

LOL, yup. The other day I saw a job opening for an MS Access developer.... At least it's just for the front-end, but I can't see why they ever bothered with it in the first place. They bought an off the shelf product and then had the company rewrite the entire thing to fit their needs. They have a dev department. So yea... before my time, but I'm gonna push for more dev work because they already pay for it and then you get custom **** :)
 
Have a look at MassTransit Service Bus (it's opensource; we use it). I also highly recommend using RabbitMQ as the queue provider for MassTransit.

Then from a web point of view, Comet or SignalR are great choices.

EDIT: semaphore beat me to it :D
 
http://msdn.microsoft.com/en-us/library/a52dhwx7(v=vs.80).aspx

SQL 2008 already has something like that. And with minimal changes to code (actually, just an addition or 2). The client application will register a dependency on the query level and sql server will let the client application know if it's changed as a once-off notification.

This will be perfect since I only need it on the edit screen of the ticket and then I can push through a nice message "Operator XYZ updated this ticket, please click refresh" and then disable the save button.

Can even apply it to the list of tickets screen, so instead of having the client call for a refresh every time, the server (when a new ticket is created) updates the clients

*NEW TOY TO PLAY WITH, YAY*
 
Gawd. OP can respond im just in awe at that remark.
lol, yes it has to be one because data integrity is very important to us

Just because a database is relational doesn't ensure data integrity - "connecting to a SQL Server database, and it's rife with data errors". Perhaps a well designed relational database, but I've seen horrible things in my time.

I don't know the full requirements of the OP, but I've seen solutions like CouchDB work and work well when it was apparently "essential" to use a RDBMS. Sure you need more validation on the application level for referential integrity, but usually that validation is there already: either by use of a framework or for example so that horrible constraint errors don't pop up when you click the Save button. I am not saying it's going to work in this case, but it shouldn't be dismissed just because it's not relational.
 
Just because a database is relational doesn't ensure data integrity - "connecting to a SQL Server database, and it's rife with data errors". Perhaps a well designed relational database, but I've seen horrible things in my time.

SQL Server already has the functionality in I was looking for. Just didn't know it was there/to search for it (or what to search for). We're a "Microsoft" house, so installing anything else would raise some eyebrows.

Having said that, have you ever had a MS Access front-end connect to a SQL Server backend? "rife with data errors" means something very simple in my language: The user interface doesn't have enough (or at all from the looks of it) error checking and the UI is very poorly designed to begin with.

This means if a person CANNOT close a ticket before adding a comment, the UI doesn't check for that (or the check is poor and sometimes slip up) which then means you have a closed ticket with no comment. Reporting off of that gets increasingly difficult depending on their report criteria and how the data needs to be "massaged" because it was captured incorrectly.

No amount of relational database design could ever account for when the UI allows for something that shouldn't happen, and I'm talking about a business rule here, not that (for example) an Order Header can exist without any Order Line Items.
 
Top
Sign up to the MyBroadband newsletter
X