As in getting spanked. Me. By ADO.NET 2.0. Which kept generating an error everytime I added a new table and delivered that DataSet in a Web Service. But in the end the Designer also gave me the info I needed to find my error.
I mentioned the other day about "tricking the Designer" in not letting it know about #temp tables in a stored procedure, so I've been pushing the designer to the limit, baby. I then started getting a web service error when including that table in the DataSet. No, no. Changing the stored proc to include #temp tables couldn't have been the problem. So my test was to add a simple SQL table with a simple query, and THAT was generating an error. So I knew it was something else.
I looked at the simple table's SQLTableAdapter and SQLDataAdapter properties in the designer (below.) The Web Service is on a secondary machine, as is the ADO.NET 2.0 Designer. And everything I tested on the machine worked fine. Then I saw it. The ConnectionString was set (by default) to the connection string generated by VS.NET. The WEB SERVICE required a connectionstring located somewhere it could access at runtime, like in an Application Property or in the web.config. Changing the ConnectionString in Properties to the string in the web.config did the trick.
Nice Properties Inspection feature in the Designer, by the way...
