Using shared data in an Outlook 2003 add-in?

I'm new to writing add-ins for Outlook and I've been working through several of the examples, but I haven’t found anything that talks about using an add-in to create and manage shared data (except using a database connection or XML document).

We need very basic CRM like functionality where contact information is shared among a group of people with additional fields. We'd also like to be able to take information from e-mails and store as notes/documents. The hands on labs and other examples I've looked at have many of the types of functions I'm looking at, but they only apply to the local client. In other words, a new contact or task that is created only seems to apply to the user who creates the item. I'd like to be able to share contact information and tasks among the whole group.

I can use a shared database for the notes capability, but doing this with a web service wrapper, the performance is pretty slow (3-5 second pause) even on a local network.

I'm probably just confused because I'm trying to switch from writing a standalone application to using Outlook and I'm hoping that I'm missing something very basic here and someone can point me in the right direction.

Thanks,
Andrew

Answer this question

Using shared data in an Outlook 2003 add-in?

caprio
Mike - thanks for your reply. < xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

I understand the mechanics of how to create, store and access data from SQL Server and also how to add fields to the Outlook repository. I guess the question was really more looking for architectural guidance on how to decide when to use one mechanism vs. the other. What should be stored in the Outlook repository and which should be in a separate data store What are the performance, access and adaptability implications of one choice or the other. Are there other things to look out for when deciding how to structure the add-in

Right now, there are 30-50 users and a few thousand "contacts". This isn't likely to grow to thousands of users, but I'd still like to make good architectural choices from the beginning.

Thanks,

Andrew
theManMyth
Andrew,

This is actually a bread-and-butter scenario and it is precisely why Windows SharePoint Services exists. What you describe in your scenario maps quite well to WSS functionality, and it is how we organize shared data among the many hundreds of teams at Microsoft.

In Outlook 2003, you can connect to WSS lists and display the shared data in Outlook, and you get all of this for FREE right out of the box. No development is needed.

If you want to customize this behavior....(drum roll)... you can do all sorts of WSS and Outlook development to make it happen.

Check out more here: http://msdn.microsoft.com/office/understanding/sharepoint

HTH!

John.
rooz
Depending on the number of clients you wish to support SQL Express would be your database of choice, You need to make the database accessible on the network which I believe is locked down by default, but this can be installed on one server or workstation if a small number of users for free and then you connect all of your clients to this and capture events in the Outlook Addin to store against this database using ADO.NET

Regards
Using shared data in an Outlook 2003 add-in?

Answer this question