My guess would be that you're not using TwoWay binding.

Also check out the MemberInfo class. One typically starts at the "member-level" (GetMembers() of the type), and then depending on the "member type" (property; method) of each member, goes from there.

Have you tried setting Mode=OneWay on the "Nae" binding? <RadioButton x:Name="Nae" GroupName="wah" IsChecked="{Binding IsChecked, Converter={StaticResource boolInv}, Mode=OneWay}"> "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

I ended up moving all the data access logic to a SQL SP using STUFF for that very reason. The data access from SQL is a snap, but loading the data into the model is time consuming. Frankly, I think that the nature of the design of the WPF screen is the issue. Each of the items is loaded into a list view and has two states, one editable state and one that is not editable. Any time you make a change to the property in the editable mode you have to fire the NotifyPropertyChanged event so that the UI will update it in the non-editable form. As a result, every single property of every row fires an OnPropertyChanged event during the initial load. I think this is likely the problem. I just don't know how to work around it. If I could avoid that initial event firing I think that things would be much quicker.

Yes, it is MVVM, I should have mentioned as much. My project is laid out as described, Business Object, Data Access Layer. The business object is responsible for retrieving the data from the database and transforming it into classes suitable for the View and ViewModel. The VM has not interaction with the DAL, just the Business Layer. That is where the dirtiness comes in, it comes from the fact that the model class would have to interact with the database where currently it is the business object that handles that. It isn't the end of the world, though. If I have the model call the business layer to retrieve the name, I won't feel so bad. Thank you for all your help. There is no strict adherence to the MVVM pattern here, more of a loose guideline, I just want to make sure that if we change our DAL we have one place to look (BizLayer) to figure out what needs to be changed. Pipedream, I am sure. Cheers, --EA

I called this LINQ Query grouping in the title but probably should have specified this is a LINQ to Entities query. I think I have it figured out now, thank you though. Cheers, --EA

The question of storing the calculated field has been on my mind actually. In theory the calculation could happen one time (Only when the record is changed) and then stored. Otherwise it happens 1500 times (The number of records roughly) every time someone needs to access the data. I think you are right that recalcing is not the best option, in spite of the fact that it has been done that way for a long time. Thanks for the input, going to move it DB side, the amount of extra storage (1 field, 1500 to 3000 records) is negligible compared to the processing benefits. Cheers, --EA

As usual, you are correct. Forgot to include the StreetSuffix in the Get. Cheers, --EA

We use SSRS for our server based reporting, Telerik will only be used for reports embedded into the application, there is no integrated viewer for any other reporting system in SilverLight. Never underestimate the power of human stupidity RAH

In VB.net its called "WITH" C# dont have this trick... But, you can use this: /// /// C# implementation of Visual Basics With statement /// public static void With(this T _object, Action _action) { _action(_object); } Usage: LongInstanceOfPersonVariableName.With(x => { x.AgeIntVar = 21; x.NameStrVar = "John"; x.NameStrVar += " Smith"; //etc.. }); from http://stackoverflow.com/a/5964848[^] I dont think its the best solution... But... It may work.

Seems like you're missing a # in the line here: data: { categoryId: $('categoryId option:selected').val() }, Should be... data: { categoryId: $("#categoryId option:selected").val() },

Its quite tricky, but try to post this question at likeplum. I always get good answers there to my computer/programming issues and questions. They have programmers online to help you now. You can get a great answer to your question so fast. https://www.likeplum.com/help/programming?aid=3321

mikepwilson wrote: IT recruiters are people who failed the ethics exam to be used car salesmen and the intelligence test to be toll takers. :laugh: :thumbsup: Ouch, but full of so much win. Thou mewling ill-breeding pignut!

Personally I'm with Tim, I consider your design the technically correct one. Technically correct is not always the best design, it is the one I prefer but if I thought storing the data would give me a better solution I'd have no compunction in changing it. Only you can asses the benefit to changing but I would think 1500 is a trivial number to deal with, add a few zeros and I'd look at it again! Never underestimate the power of human stupidity RAH