views:

68

answers:

1

I have a domain service, derived from LinqToEntitiesDomainService<FOOEntities>

It has one method, IQueryable<Bar> GetBar(). GetBar returns a LINQ query on the entity model. The LINQ works fine in LINQPad.

In the XAML of a Silverlight thingy, I have a ListBox whose ItemsSource points to a DomainDataSource defined in the same XAML file, named dsGetBar. AutoLoad="True" on dsGetBar. I have an empty handler for the dsGetBar's LoadedData event.

I run this in VS2010. When I attach to both the WebDev.WebServer process and the browser instance, and load the page, I hit breakpoints in GetBar() and in the LoadedData handler. From this I optimistically infer that the service is getting called by the client.

In GetBar(), I call queryresults.Count, which returns 24,000 and change. My method returns fine, without throwing any exceptions.

So here's the problem:

In LoadedData, dsGetBar.Data.Count == 0. No items ever appear in the ListBox. In case my ListBox item template was broken, I tried it with a DataGrid instead. Same deal.

Is Data where the data should be? If not, where? Is ItemsSource the correct property to use when you want to provide a control with a source of items?

Is there any known way to find out what is going on between the service and the client?

UPDATE

The service returns a 504 ("ReadResponse() failed: The server did not return a response for this request.") after the query method successfully completes.

UPDATE

The 504 happened because the number of records exceeded 65,535. Only 24,000-odd made it past a where clause in the LINQ (it would be 74,000 without the where clause), so this isn't even a limitation on what can go through the wire. Absurd. That number is microscopic.

I think what we've learned is that the Entity Framework isn't ready for use in software just yet.

+2  A: 

You can use Fiddler to see what's going on between client and server. It's a browser proxy that intercepts all browser traffic so that you can see what's happening.

I don't know what goes wrong, unfortunately.

Ronald Wildenberg
Thank you! Big help.
Ed J. Plunkett