InfoPath Dev

Hi,

I know that adding replication to an underlying SQL database will modify all tables so that each record contains a GUID used to track add/deletes/updates between servers - but this also seems to break InfoPath forms as these new fields are not expected and probably causing primacy errors to occur.  Is there an easy way of fixing this when the forms are published within a SharePoint document library (or is it list?).

We've got a system that's been running for a year now, so plenty of data in there.  If we modify our forms then we won't be able to open existing forms (from what I'm told).

Any ideas/pointers?

Thanks

Davie

Hi Davie,

So you have forms saved to SharePoint and those forms are also submitting to SQL? Is that correct? If the SQL DB has changed, you can use Tools->Convert Main Data Source, but you are right that this will invalidate the old forms because the InfoPath-SQL is a tight coupling. We advocate using Web Services and data-driven loose-coupling so that you can make changes in either the form or the DB without breaking your previous forms or your live submission process. I've blogged this limitation recently with our Web Service solution: http://www.infopathdev.com/blogs/patrick/archive/2010/01/29/infopath-gaps-in-sharepoint-and-sql.aspx.

Unfortunately, I don't think you have a quick fix. You could move to a loosely coupled architecture, and keep your old data as is, but depending on the complexity of your schema, it could take some work to map the database derived schema to your existing DB. If it's <100 fields, probably not a huge deal, but I'm guessing more than eight hours. We have done this before for several companies who got in a similar situation and can give you references if you're interested.