Hmm. I would say that your business level entities coming from your data layer have no business at all in your GUI layer. It seems as if you do not have a layered application and that is your first problem. At the minimum, I'ld say a GUI layer, business layer and data layer is essential. Your mvvm pattern is found in your GUI layer and deals exclusively with GUI stuff. Use dto's to send data from and to your business. Your project will look like a bowl of spaghetti if you don't structure it properly.

Okay, I found how to make it compile: remove the assembly directive from the namespace declaration: ... This works: ... Now for my other question, where did the compilation product go ? And more importantly, how do I get at it ?

It works perfectly, thanks a lot !

You cant do that in XAML, because you need to check which listbox width is higher. You can add event handler on event which occurs when you already know widths of both listboxes. For examole: Loaded, Binding.SourceUpdated or smth like this. Also, if you want to avoid streching of listbox, you have to set colums width="auto": <ColumnDefinition Width="auto" />

Ian Shlasko wrote: Ugh, typical unhelpful Xaml/Baml traces... Really wish Microsoft would put some useful information in there. Really wish Microsoft would give the source code like they used to for the CRT :laugh: I'm very happy with the Style-based solution, thanks.

Ok I found the solution here: use a List instead of a string[].

Oh right... sorry, yeah, I forgot some of the view classes randomly make useful properties read-only :). Ok, well, then there are a few ways you can proceed. 1) You are getting BindingListCollectionView because you are binding to a source that implements IBindingList. So you can repackage the data in something different like an ObservableCollection, etc. 2) You can try wrap your source in a CollectionViewSource. CollectionViewSource requires the source to implement IEnumerable which should work for you. #2 is probably easier, but if that doesn't work, you'll have to do #1 :). It kind of makes sense that what you are trying to do is not really supported directly.

Recreate everything from scratch. The classes involved are going to be different and there is stuff that the SQL Server classes supports that the ODBC classes do not. By using ODBC instead of the SQL Server dedicated classes you are also giving up the flexibility and performance benefits of the dedicated classes. A guide to posting questions on CodeProject[^] Dave Kreskowiak

Jean-Louis Leroy wrote: the proper .NET way, e.g. use DataSets instead of raw SQL. That's the lazy way; it leads to poor quality and frustrations like you have now. Jean-Louis Leroy wrote: What would you recommend ? Just use SQL; it sounds like you know how. Read this[^].

Is CurrentUser as row? If so then simply get the column value from the datarow. You may need another property or you may be able to bind to required columns value. Never underestimate the power of human stupidity RAH