InfoPath Dev

There are in most organizations some groups of data that would be useful to share across site collections and farms - for example, lists of valid department numbers, department names, divisions, VP names, admin names, staff names, etc.

I know that if I try to create a simple out of the box SP 2010 custom list with a lookup column, that column can only look at lists on the site itself.

Within InfoPath 2010, is it possible to create data connections to custom lists that exist on one farm and one site collection and then use those data connections within InfoPath applications on other site collections, farms, etc.?

If that is possible, is there a tutorial, web video, book or magazine article, etc. that walks someone through the process of setting that up?

Thank you so much!

I've found this kind of thing tricky in SharePoint let along InfoPath.

As perhaps you've discovered there are many places for lots of data, much of it the same and repeated

Why not create a SQL database/view(s)?

Then all information would be correct and in 1 place.

Then  you could at least use that as an external list to make sure all your data is up to date and correct etc.

Cross Site/Cross web app doesn't place nicely.

In an environment where one has to create a business case, argue the request like defending a thesis, etc. versus creating a sharepoint list, the list is exceptionally appealing.

Trying to teach people how to add and modify the data via a SP list is also much easier versus some other method of updating the data in a database.

Further You could tie that SQl list to a sp page and give users update and delete permission. Within reason.

I started out looking for a way to have one list somewhere on SharePoint that infopath lookup columns could make use of. While having the data stored in SQL Server is certainly a possibility, as is tying a SharePoint list to the SQL Server table for input and query, I am still left trying to figure out how to have one list. It seems to me I am left creating multiple SharePoint lists tied to the SQL Server table, and that is not ideal - any time a significant change to the table has to occur, then I have to try and figure out all the places that people have created the ties between the table and lists. I