InfoPath Dev

As an InfoPath newbie, I've worked through several tutorials & exercises to work with data via main and secondary data sources. Regardless of whether I'm using a local MS Access database or an ODBC connection to a SQL Server database on our network, I get the following message when using the form in Fill In mode:

ADO Security Warning
This Website uses a data provider that may be unsafe. If you trust the website, click OK, otherwise click Cancel.

If I click OK I get the data just fine. But I'd like to suppress this message if I can. Can I do that? Am I just doing something wrong?

Any help would be appreciated. Sorry if I missed an already-posted answer.

Hi quelcjlx and welcome to the InfoPathDev forums!

I think you can eliminate that message by making the form fully trusted - in other words digitally signing the document.

And this post might help you out:

http://infopathdev.com/forums/topic.asp?TOPIC_ID=134

Hope that helps!

Thanks, Ted. That helps, but -- if I understand correctly -- the only way to have others use fully trusted forms is for the forms to be installed individually for each user, preferably via an MSI package. The implication is that if it is a requirement that I make these forms accessible from a intranet web link, I'm stuck with the warning message. True?

From what I understood when I had this problem it could be rectified by using a digital certificate and signing the form. Without an understanding of this we didn't get it to work and resorted to changing the relevant IE settings. however this had to be done for each user (someone else took care of that, semi-automatable?).

Our form is in a sharepoint library.

In security settings try setting
Access Data Sources Across Domains
to Enable
instead of Prompt.

We also had another similar message that went away when the
Logon setting was changed to
Automatic Logon with Current Username and Password
instead of Automatic Logon Only in Intranet Zone.

Also be sure to add the hosting server to trusted sites.

And someone please correct me if I'm wrong, this stuff isn't my strong point >.<

quote:

---

Originally posted by quelcjlx

Thanks, Ted. That helps, but -- if I understand correctly -- the only way to have others use fully trusted forms is for the forms to be installed individually for each user, preferably via an MSI package. The implication is that if it is a requirement that I make these forms accessible from a intranet web link, I'm stuck with the warning message. True?

---

Hi,

Thinking about this some more, it seems strange to me that you would get that ADO warning on a local (your computer, not network) MDB file. The SQL DB on a network makes more sense, but the local MDB file is strange.

Have you tried replicating this issue on a different computer with the Access file? For some reason I am thinking that ADO message is related to a security setting on your computer or network?

UPDATE: I just looked up some information in the Halstead/Vani Mandava-Teredesai/Blain book:

http://www.amazon.com/exec/obidos/ASIN/0735621160/infopathdev0b-20

and your issue *could* be coming from cross-domain access. Page 173 says "...you might run into security restrictions due to cross-domain access when you open a form on the local machine that uses a database also on the local machine."

The workaround is to register the form using "RegForm" which is part of the InfoPath SDK tool. OR, change your IE security settings, which gets to what Sam was talking about above. As Sam says, the book also suggests changing to a custom security level within IE, enabling "Access Data Sources Across Domains" (enable from prompt).

Hope this is of some help and good luck!

As a thought, after recently reading up on VBScript and the send keys ability, would it be possible to write a script that automatically acknowledges these messages without user interaction? It would have to be internal to the form, and I don't know how you'd trigger it or... anyways, just a thought

Thanks, SamDahl. I'll look into the scripting angle. Referencing your earlier post where you mention changing security settings, are you referring to browser settings or sharepoint settings? (At this time, we are NOT using sharepoint services.) I've tried changing browser settings with no apparent effect while trying to run my form from my local machine. Thanks again for your interest.

J.L.,

Yes it's the browser settings you want to change.

Is this just happening with one form? Can you try opening the form on another machine to see if it happens there and can you try making a brand new test form calling to the same Access mdb to see if it's some type of strange issue with the form iteslf?

Indeed it was the browser settings.
In reference to the scripting idea I'm still not entirely sure if it's feasible but if it is then it's something I'd like to do if someone can offer some help in how to go about it.

Ok, changing the browser settings eliminated one warning, but when trying to use NT authentication rather than SQL authentication when connecting to the SQL Server database, I get the ADO warning:

This website is using your identity to access a data source. If you trust this website, click OK to continue, otherwise click Cancel.

Not only is that an issue, but our server configuration and corporate policies make it undesirable to override default browser settings.

Installing as a fully trusted form seems to work, but we were hoping for a solution that allows our users to access the forms via web link.

I haven't had time to investigate the Send Key scripting idea, but hope to get to that soon.

Thank you both for the help. If I haven't yet found a solution, at least the problem is in better focus for me now.

I think the problem is solved. Changing browser settings company-wide to less restrictive data access is evidently not necessary in our scenario. It turns out that simply adding the hosting server to trusted sites does the trick. Since the hosting server will be our own public Internet site, this does not constitute a security exposure in the eyes of our system services folks. Thanks again for your help and suggestions -- it definitely put me on the right path to the solution.