Returning data to WCF / .NET

Question

I have a WCF service from which I want to return a DataTable. I know this is often a debatable topic about whether the data in the DataTables is true or not. Let's stop for a moment.

When I create a DataTable from scratch, as shown below, there is no problem. The table is created, populated and returned to the client, and all is well:

[DataContract] public DataTable GetTbl() { DataTable tbl = new DataTable("testTbl"); for(int i=0;i<100;i++) { tbl.Columns.Add(i); tbl.Rows.Add(new string[]{"testValue"}); } return tbl; } 

However, as soon as I exit and enter the database to create a table, as shown below, I get a CommunicationException "The main connection was closed: the connection was unexpectedly closed."

 [DataContract] public DataTable GetTbl() { DataTable tbl = new DataTable("testTbl"); //Populate table with SQL query return tbl; } 

The table is populated correctly on the server side. It is much smaller than the test table through which I looped and returned, and the request is small and fast - there are no problems with timeouts or large data transfers. The exact functions used are DataContracts / ServiceContracts / BehaviorContracts.

Why does the way the table is populated has anything to do with the table being returned?

Answer 1

For those who have similar problems, I solved my problem. This has been several times.

• As Darren suggested, and Paul supported, the Max..Size properties in the configuration needed to be increased. The SvcTraceViewer utility helped determine this, but it still does not always give the most useful error messages.
• A message also appears that when a service link is updated on the client side, the configuration is sometimes not updated properly (for example, changing the configuration values ​​on the server will not always be correctly updated on the client. I had to log in and change Max..Size several times to client and server side during my debugging)

• In order for a DataTable to be serializable, it must be given a name. The default constructor does not give the table a name, therefore:

   return new DataTable(); 

  will not be serializable, but:

   return new DataTable("someName"); 

  will indicate a table that is passed as a parameter.

  Note that you can name the table at any time by assigning a row to the TableName DataTable property.

   var table = new DataTable(); table.TableName = "someName"; 

Hope this helps someone.

Answer 2

The best way to diagnose these WCF errors (those that don’t really tell you very much) is to enable tracing. In the web.config file, add the following:

  <system.diagnostics> <sources> <source name="System.ServiceModel" switchValue="Information" propagateActivity="true"> <listeners> <add name="ServiceModelTraceListener" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="wcf-traces.svclog"/> </listeners> </source> </sources> </system.diagnostics> 

Then you can open the resulting file in the SvcTraceViewer.exe utility, which is included in the SDK.NET Framework (or with Visual Studio). On my machine, it can be found in the% PROGRAMFILES% \ Microsoft SDK \ Windows \ v6.0A \ Bin \ SvcTraceViewer.exe folder.

Just find the error message (highlighted in bold red) and it will definitely tell you what the problem is.

Answer 3

In addition to setting maximum values ​​for all binding attributes.

Make sure that every table you pass / return from webservice should have a table name, i.e. the table.tablename property table.tablename not be empty.

Answer 4

I added Datable to the dataset and returned the table like this ...

 DataTable result = new DataTable("result"); //linq to populate the table Dataset ds = new DataSet(); ds.Tables.Add(result); return ds.Tables[0]; 

Hope this helps :)

Answer 5

The attribute you want is OperationContract (by interface) / Operation Behavior (on method):

 [ServiceContract] public interface ITableProvider { [OperationContract] DataTable GetTbl(); } [OperationBehavior] public DataTable GetTbl(){ DataTable tbl = new DataTable("testTbl"); //Populate table with SQL query return tbl; } 

Also, in ... I think the service setting ... you want to indicate that errors may be sent. You may have encountered an error that is something like message size, large, etc. You can fix this by indulging in reading quotas, etc.

By default, wsHttpBinding has a receive size quota of 65 KB, so if an XML table with serialized data is larger than this, it will throw an error (and I'm 95% sure that the data table is more than 65 KB with the data in it).

You can change read quota settings, etc. in web.config / app.config or you can install it on a binding instance in the code. But yes, maybe this is your problem if you have not changed it by default.

WSHttpBindingBase Members - Look at the ReaderQuotas property, as well as the MaxReceivedMessageSize property.

Answer 6

You have probably reset your quota - the data size is larger than the allowed maximum packet size for your connection.

You probably need to set MaxReceivedMessageSize and MaxBufferSize to higher values ​​in your connection.

Answer 7

There are 3 reasons for a failed return type as datatable in WCF services

• You need to specify the name of the data table, for example:

   MyTable=new DataTable("tableName"); 

• When you add the link on the client side of the WCF service, select the reused system.data dll

• Specify the attribute in the datatable member variable as

   [DataMember] public DataTable MyTable{ get; set; } 

Answer 8

I think Darren is most likely right - the default values ​​for WCF are ridiculously small, and if you run into them you will get errors that are hard to track down. They seem to appear as soon as you try to do something other than a simple test. I spent more time than I would like to acknowledge debugging problems that turned out to be related to various configuration settings (size) both on the client and on the server. I think that I eventually changed almost all of them, for example. MaxBufferPoolSize, MaxBufferSize, MaxConnections, MaxReceivedMessageSize, etc.

Having said that, the mentioned SvcTraceViewer utility is also wonderful. I came across several cases when it was not as useful as I would like, but overall it is a good tool for analyzing message flow and errors.