 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / General MS InfoPath Questions / February 2006VS 2005 web service
Does anybody have an example of a web service in VS 2005 that returns a dataset or datatable that works with Infopath? Since the ADO.NET 2.0 changes, I haven't been able to figure out how to build a web service in VS 2005 that doesn't produce a schema error in Infopath. All worked fine in VS 2003 but in 2005 I get various diffgram and/or schema errors when I return a typed dataset, typed datatable, or generic dataset. I am experiencing a similar problem. I am using SQL Server 2005 and I exposed an endpoint as a web service from SQL Server 2005. I added one single web method based on a simple stored procedure that executes a select on a table in the database. I can see the web service in InfoPath, I can see the web method, but whenever I want to use it in InfoPath (e.g. as a secondary datasource for a drop down control) I get this error message: /schema/complexType[1][@name='SqlRowSet']/sequence[1]/element[1], Undeclared XSD element:'{http://www.w3.org/2001/XMLSchema}-schema'. > Does anybody have an example of a web service in VS 2005 that returns a > dataset or datatable that works with Infopath? Since the ADO.NET 2.0 changes, [quoted text clipped - 3 lines] > All worked fine in VS 2003 but in 2005 I get various diffgram and/or schema > errors when I return a typed dataset, typed datatable, or generic dataset. Same experiences over here. It's really too stupid. The shame: It is a known bug since one year! http://support.microsoft.com/?scid=kb;en-us;889494&spid=2515&sid=251 According to the Office SP 2 bug fix list this issue hasn't been fixed with SP 2 Seems we are all forced to return "Hello World". I couldn't get more out of InfoPath since it's first incarnation, although I'm willing to use it, really! Regards > Does anybody have an example of a web service in VS 2005 that returns > a dataset or datatable that works with Infopath? Since the ADO.NET [quoted text clipped - 4 lines] > schema errors when I return a typed dataset, typed datatable, or > generic dataset. Same problem here. I thought I had really improved my infopath application by condensing what was 5 separate database calls to populate dropdowns into a single web service call that returns a dataset, but it appears i'm having the same problem. I'm using vs 2005, i guess i could go back to 2003, but that's not the direction i was really wanting to move in. We have found InfoPath to be a good tool with the potential to be great, but there are some serious drawbacks that have caused us to choose a different route for our next project with similar requirements.  SignatureJosh Meyer Senior Systems Analyst The Trident Group, Inc. > Does anybody have an example of a web service in VS 2005 that returns a > dataset or datatable that works with Infopath? Since the ADO.NET 2.0 changes, [quoted text clipped - 3 lines] > All worked fine in VS 2003 but in 2005 I get various diffgram and/or schema > errors when I return a typed dataset, typed datatable, or generic dataset. Josh, meanwhile I found a workaround, which seems OK for me (http://support.microsoft.com/kb/822020/en-us). Im using workaround #1. I put all my functions into a new .asmx, wich resides besides the other modules (which return datasets and stuff). This is necessary, because IP does not accept the co-existence of functions which return datasets together with those, which return ordinal or less complex types in one module. The new webfunctions in the new asxm do use the same core, as the other functions with same names do, but do convert each result into a System.Xml.XmlDocument. This can be consumed by IP. e.g [WebMethod] public System.Xml.XmlDocument service_xml(int para) { System.Xml.XmlDocument xmldoc = new System.Xml.XmlDocument(); xmldoc.LoadXml(service_dataset(para).GetXml()); return xmldoc; } After that I connect IP with the new .asmx Regards > Same problem here. I thought I had really improved my infopath > application by condensing what was 5 separate database calls to [quoted text clipped - 15 lines] >> schema errors when I return a typed dataset, typed datatable, or >> generic dataset. Thanks! I'll definitely have to give that a try. josh Josh, seems, that Office SP 2 has fixed that problem, although the fix is not mentioned in the list of fixes for IP. I'm - oh wonder - now able to consume ADO datasets withing IP! At least receiving. I didn't test sending up to now... Could you please doublecheck? Regards > Thanks! I'll definitely have to give that a try. > > josh Sorry guys, but the SP2 fix and the XMLDocument approach are old news and not fixing my VS2005 problem. A dataset from VS2003 can be consumed by I/P directly. A dataset from VS2005 can't. The default response for VS2005 is now a datatable rather than a full dataset. I'm wondering if anyone has some sample code in VS2005 that produces an XML stream that I/P can consume. What took 5 lines of code in VS2003 now only requires 2 lines of code in VS2005 but the result can't be consumed by I/P. A solution for using VS2005's efficiencies would be great. > Josh, > [quoted text clipped - 11 lines] > > > > josh Jerry, you're not right. My WS is a VS2005 WS. It produces DataSets and IP SP 2 consumes it. Please doublecheck. Regards > Sorry guys, but the SP2 fix and the XMLDocument approach are old news > and not fixing my VS2005 problem. A dataset from VS2003 can be [quoted text clipped - 21 lines] >>> >>> josh That's great news. So now I'm perplexed. By default when I use VS 2005 to prepare an XSD it creates a DataTable rather than a DataSet. Then I use the following two lines of code (as an example): Public Function ProjectList(ByVal EmployeeID As String) As Project.ProjectDataTable Dim ProjectTA As New ProjectTableAdapters.ProjectTableAdapter() Return ProjectTA.GetData() End Function This function returns a great looking XML statement when run in IE but Infopath can't consume it. Are you not using the default DataTable XSD in VS2005 in order for Infopath to consume it? Thanks for your help. > Jerry, > [quoted text clipped - 29 lines] > >>> > >>> josh Hi Jerry, what I'm usually doing with my webservices is to return DataSets sometimes rather than some sort of wrapper classes. This is a bit hard wired, I know, because if the structure of the underlaying tables ís changing, everything on the webservice consumer side has to be changed too. But it's fast to develop and easy to handle. I'm using C#. Here is a sample webservice function, which wasn't consumable by IP before applying Office SP2, but which is now perfectly consumable by IP. [WebMethod] public DataSet db_select_something(Int64 id) { SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString); SqlCommand command = new SqlCommand("db_select_something", connection); command.CommandType = CommandType.StoredProcedure; command.Parameters.Add(new SqlParameter("@id", id)); SqlDataAdapter adapter = new SqlDataAdapter(command); DataSet ds = new DataSet(); adapter.Fill(ds); return ds; } This fits perfectly into the IP world, regardless of how many tables the returning dataset contains. The function is working against a Stored Procedure on a MS SQL server, but this doesn't matter. Returning an empty DataSet should work too. In IP I'm creating a new form from a datasource, selecting "webservice", selecting "receive data" and providing the URL of the webservices WSDL e.g. http://localhost/webservices/mywebservice.asmx?WSDL and providing the name of the db_select_something function. The IP wizard asks for a sample value for the ID parameter. You should enter a value here, which is available in the underlaying data table, because IP asks the webservice in order to retrieve the structure of the returned dataset. That's it. After that you are free to design your form. Regards > That's great news. So now I'm perplexed. By default when I use VS > 2005 to prepare an XSD it creates a DataTable rather than a DataSet. [quoted text clipped - 52 lines] >>>>> >>>>> josh Jerry, I tried it your way. And indeed you are right: This does not work. Probably this link does help you out here (let me know if yes) http://groups.google.de/group/microsoft.public.infopath/browse_frm/thread/e1bac8 4f0b0aa860/32ea31583b3a6def?lnk=st&q=dataset-diffgram&rnum=18&hl=de#32ea31583b3a 6def Unfortunately my MSDN subscription expired, so I cannot comment whether the new toolkit does fix the bug (it _is_ a bug) or not. Regards > That's great news. So now I'm perplexed. By default when I use VS > 2005 to prepare an XSD it creates a DataTable rather than a DataSet. [quoted text clipped - 52 lines] >>>>> >>>>> josh Thanks for the post Neil. As a work around I've had generic result sets similar to your example. I bummed though, because I would like to use a strongly typed result so I can control datatypes a little more. This approach worked fine in VS 2003 but I can't get it to work in VS 2005 (of course it "works" in VS 2005 just not with IP). I had reviewed the article you provided earlier and did load the Office tools to see if the problem was resolved but I couldn't see any difference in behavior. What even has me more puzzled is that VS 2005 has been out for 3 months and I can't find one example from Microsoft on using VS2005 for building an Infopath web service. I would have thought that there would be many tutorials by now. Other than the Office tools for VS2005 I can't even find an article on MSDN that mentions VS2005 and Infopath 2003 in the same context. The silence is noticable... > Jerry, > [quoted text clipped - 64 lines] > >>>>> > >>>>> josh |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.