WPF/LinqToSql/DataGrid

[Bill McCormick]

Linda Liu[MSFT] wrote:

[snip]

parent record in the JobOrderTable. Due to the improper data type of the
DspPltSide field in the Dsp table, the FormatException occurs.

Again, I'm having a serious problem with this if your saying that
LinqToSql cannot process varchar(1) data fields.

The above behavior of LINQ to SQL is called deferred loading, which means
when you query for an object, you actually retrieve only the object you
requested. The related objects are not automatically fetched at the same
time. You cannot see the fact that the related objects are not already
loaded, because an attempt to access them produces a request that retrieves
them.

Your understanding of the subject matter specific to deferred loading
notwithstanding, I think you are missing my point: that is that the
exception SHOULD be able to be caught at the user (form) level. If in
fact it can only be caught at the application level by looking for
Unhandled exceptions, I think this is not proper design.

Since the data retrieving happens in the main UI thread, we can capture
this FormatException by handling the
Application.DispatcherUnhandledException event. Open the App.xaml file and
add the following attribute to subscribe the DispatcherUnhandledException:

<Application x:Class="ScAggScale.App"

DispatcherUnhandledException="Application_DispatcherUnhandledException"
....>

In the App.xaml.cs file, add the following event handler:

public partial class App:Application
{
private void Application_DispatcherUnhandledException(object sender,
System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
MesssageBox.Show("Unhandled Exception:" + e.Exception.Message);
e.Handled = true;
}
}

Anyway, this is how I've handled it for now, except I believe it is more
proper to shutdown the application at this point. When handling
exceptions that have bubbled to the top like this, you have to consider
that the application may have been left in some improper state. Leaving
the application running for all unhandled exceptions should be avoided.



Bill

 

[Bill McCormick]

Linda Liu[MSFT] wrote:

[snip]

parent record in the JobOrderTable. Due to the improper data type of the
DspPltSide field in the Dsp table, the FormatException occurs.

Again, I'm having a serious problem with this if your saying that
LinqToSql cannot process varchar(1) data fields.

The above behavior of LINQ to SQL is called deferred loading, which means
when you query for an object, you actually retrieve only the object you
requested. The related objects are not automatically fetched at the same
time. You cannot see the fact that the related objects are not already
loaded, because an attempt to access them produces a request that retrieves
them.

Your understanding of the subject matter specific to deferred loading
notwithstanding, I think you are missing my point: that is that the
exception SHOULD be able to be caught at the user (form) level. If in
fact it can only be caught at the application level by looking for
Unhandled exceptions, I think this is not proper design.

Since the data retrieving happens in the main UI thread, we can capture
this FormatException by handling the
Application.DispatcherUnhandledException event. Open the App.xaml file and
add the following attribute to subscribe the DispatcherUnhandledException:

<Application x:Class="ScAggScale.App"

DispatcherUnhandledException="Application_DispatcherUnhandledException"
....>

In the App.xaml.cs file, add the following event handler:

public partial class App:Application
{
private void Application_DispatcherUnhandledException(object sender,
System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
MesssageBox.Show("Unhandled Exception:" + e.Exception.Message);
e.Handled = true;
}
}

Anyway, this is how I've handled it for now, except I believe it is more
proper to shutdown the application at this point. When handling
exceptions that have bubbled to the top like this, you have to consider
that the application may have been left in some improper state. Leaving
the application running for all unhandled exceptions should be avoided.



Bill

 

[Linda Liu[MSFT]]

Hi Bill,

Thank you for your reply!

I look closer to your sample database and find out the real cause of the
problem.

Since the data type of the DspPltSide field in the Dsp table is varchar(1),
this field accepts an empty value ''. Actually, I find a lot of records in
the Dsp table have the value of '' in the DspPltSide field.

On the other hand, the DspPltSide property of the ScAggScale.DataMode.Dsp
class in your application is of type Nullable<char>, which doesn't accept
the value of ''. So when LINQ to SQL retrieves records from the Dsp table
which contain the empty value '' in the DspPltSide field and tries to
assign the value of '' to the DspPltSide property, the FormatException
occurs.

In my previous reply, I mentioned if I modify the data type of the
DspPltSide field in the Dsp table to char(1), the problem disappers. Later
I find that this works because the value of '' in the DspPltSide field is
changed to ' ' automatically when the data type of the DespPltSide field is
changed from varchar(1) to char(1).

As for capturing the FormatException, it's difficult to capture the
exception from the form level because it 's not the source code you write
that raise the exception.

Hope this helps.
If you have any concern, please feel free to let me know.


Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Linda Liu[MSFT]]

Hi Bill,

Thank you for your reply!

I look closer to your sample database and find out the real cause of the
problem.

Since the data type of the DspPltSide field in the Dsp table is varchar(1),
this field accepts an empty value ''. Actually, I find a lot of records in
the Dsp table have the value of '' in the DspPltSide field.

On the other hand, the DspPltSide property of the ScAggScale.DataMode.Dsp
class in your application is of type Nullable<char>, which doesn't accept
the value of ''. So when LINQ to SQL retrieves records from the Dsp table
which contain the empty value '' in the DspPltSide field and tries to
assign the value of '' to the DspPltSide property, the FormatException
occurs.

In my previous reply, I mentioned if I modify the data type of the
DspPltSide field in the Dsp table to char(1), the problem disappers. Later
I find that this works because the value of '' in the DspPltSide field is
changed to ' ' automatically when the data type of the DespPltSide field is
changed from varchar(1) to char(1).

As for capturing the FormatException, it's difficult to capture the
exception from the form level because it 's not the source code you write
that raise the exception.

Hope this helps.
If you have any concern, please feel free to let me know.


Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Bill McCormick]

Hi Bill,

Thank you for your reply!

I look closer to your sample database and find out the real cause of the
problem.

Since the data type of the DspPltSide field in the Dsp table is varchar(1),
this field accepts an empty value ''. Actually, I find a lot of records in
the Dsp table have the value of '' in the DspPltSide field.

On the other hand, the DspPltSide property of the ScAggScale.DataMode.Dsp
class in your application is of type Nullable<char>, which doesn't accept
the value of ''. So when LINQ to SQL retrieves records from the Dsp table
which contain the empty value '' in the DspPltSide field and tries to
assign the value of '' to the DspPltSide property, the FormatException
occurs.

In my previous reply, I mentioned if I modify the data type of the
DspPltSide field in the Dsp table to char(1), the problem disappers. Later
I find that this works because the value of '' in the DspPltSide field is
changed to ' ' automatically when the data type of the DespPltSide field is
changed from varchar(1) to char(1).

The acceptable solution turns out to be a modification to the DB
DataModel entity class; changing the field datatype in the entity class

As for capturing the FormatException, it's difficult to capture the
exception from the form level because it 's not the source code you write
that raise the exception.

Another solution is to try/catch in the event that is triggered when
clicking on the data row. I've not yet tried this, but I will. If anyone
is interested, contact me at wpmccormick at just about anywhere (gmail,
yahoo, hotmail) and I'll let you know how it turned out.


Thanks.

 

[Linda Liu[MSFT]]

Thanks Bill for the information!

The acceptable solution turns out to be a modification to the DB

DataModel entity class; changing the field datatype in the entity class
from nullable<char> to string.

In fact, I also found this solution when I researched on your sample
project. IMO, the real cause of the problem is the empty value '' in the
DspPltSide field in the Dsp table.

Either changing the DB DataModel entity class's field datatype from

Another solution is to try/catch in the event that is triggered when

clicking on the data row.

It's the LINQ to Sql that retrieves data from database and fill the data
into the data model entity objects. All this is done internally. IMO, I
don't think we can capture the FormatException in the event that is
triggered when clicking on the data row.

Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Bill McCormick]

Thanks Bill for the information!

DataModel entity class; changing the field datatype in the entity class
from nullable<char> to string.

In fact, I also found this solution when I researched on your sample
project. IMO, the real cause of the problem is the empty value '' in the
DspPltSide field in the Dsp table.

Then, on this point, we'll just have to "agree to disagree"

Either changing the DB DataModel entity class's field datatype from

clicking on the data row.

It's the LINQ to Sql that retrieves data from database and fill the data
into the data model entity objects. All this is done internally. IMO, I
don't think we can capture the FormatException in the event that is
triggered when clicking on the data row.

OK, I'm going to give it the old college try anyway. If it doesn't work,
I'll re-open my case.


Thanks for all your help,


Bill

 

[Linda Liu[MSFT]]

You're welcome, Bill!

I'm very impressed with and admire your insistence : ) It's my pleasure to
work with you.

If you need assistance on this particular issue, please feel free to
re-open it and I will continue to follow up with you.

Have a nice day!

Sincerely,
Linda Liu
Microsoft Online Community Support