I've just discovered a really slick way to access data that is related to the row you are working with in a DataTable.
Previously, if I was working with data with one table (lets say Employees) and I wanted to find all the orders with a particular employee, I would go about it something like this:
EmployeesTableAdapter eta = new EmployeesTableAdapter();
EmployeesDataTable edt = pta.GetEmployee();
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
The cool thing about the code generated is that the class information is created as partial classes. With the use of partial classes, we can extend the partial class in our own code and as such, extend the functionality that is available for a particular row.
public partial class SuppliersRow
{
public EmployeesDataTable GetEmployeesOrders()
{
OrdersTableAdapter ota = new OrdersTableAdapter();
return ota.GetOrdersByEmployeeID(this.EmployeeID);
}
}
With the functionality extended, we can have the row we are working with be responsible for retrieving the data associated with that row.
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
Tuesday, April 3, 2007
Monday, February 12, 2007
Debug timeout with IIS 7.0 and App pools
I've been having problems debugging my web applications for the past month or so after I upgraded to vista.
Problem:
When my application was broken into the debugger, after ~90 seconds, the debugger would stop working and I would have to restart it.
Looking into the eventlog, I found the following notices:
A process serving application pool ''failed to respond to a ping. The process id was '5472'.
Source of the Problem:
IIS has a setting for application pools that allows it to monitor the health of the process. When the process doesnt respond to a ping request (as in debug mode), IIS kills the process and therefore kills the debug session.
Solution:
1. Open IIS
2. Open the Advanced Settings for the application pool you are running under.
3. Find the setting "Ping Enabled" under "Process Model"
4. Change this to False.
Note: you could alternatively increase the Ping Maximum Response Time to a higher value.
Problem:
When my application was broken into the debugger, after ~90 seconds, the debugger would stop working and I would have to restart it.
Looking into the eventlog, I found the following notices:
A process serving application pool ''failed to respond to a ping. The process id was '5472'.
Source of the Problem:
IIS has a setting for application pools that allows it to monitor the health of the process. When the process doesnt respond to a ping request (as in debug mode), IIS kills the process and therefore kills the debug session.
Solution:
1. Open IIS
2. Open the Advanced Settings for the application pool you are running under.
3. Find the setting "Ping Enabled" under "Process Model"
4. Change this to False.
Note: you could alternatively increase the Ping Maximum Response Time to a higher value.
Subscribe to:
Posts (Atom)