What do you do when no records returned in Fetch, error

ltgrady posted on Monday, September 18, 2006

Using vs1.5. The object retrieves records based on the User's ID. So I pass that in and call the sproc in the object's Fetch. But some Users don't have this information. So in my page code I want to check if/null on something.

When I run my object the dr.read() causes:

Invalid attempt to read when no data is present

Obviously I can just do a dr.recordsaffected = -1 and skip the dr.read section. However, what do you normally do with the object? Set the values to null? Somehow set the object to null? Is there any standard CSLA practice people are using?

DeHaynes replied on Monday, September 18, 2006

I am not using version 1.5 but I use the following line to ensure I don't run into this situation.

while (dr.Read())
{
this.Add(ProjectResource.GetResource(dr));
}

This is an example from Rocky's Resources.cs object.

ChristianPena replied on Tuesday, September 19, 2006

I am fairly new to CSLA so there may be some subtlety that I am missing. I guess I am wondering why the response posted by DeHaynes is not the right response. Typically you would do this in a parent object or list and so the code provided by Tim would ensure that the case does not happen.

JoeFallon1 replied on Tuesday, September 19, 2006

ChristianPena:

I am fairly new to CSLA so there may be some subtlety that I am missing. I guess I am wondering why the response posted by DeHaynes is not the right response. Typically you would do this in a parent object or list and so the code provided by Tim would ensure that the case does not happen.

That code is correct for a Parent/Child BO relationship.

The question should have stated that is was about a Root BO. Then you have the dilemma of what to do when the PK value you are searching for does not exist in the DB. Do you return Null, an Exception or a New BO?

Joe

RockfordLhotka replied on Monday, September 18, 2006

There was a big discussion about this a while ago. Search for the null object pattern to find that thread.

In general, I recommend letting the exception bubble up to where you can do something about it (like tell the user the data couldn't be found). Other people prefer to return a null object or take other steps.

JoeFallon1 replied on Monday, September 18, 2006

I have a test in my code to see if the record exists before trying to fetch it. If it does then I do a normal Fetch. But if it does not, I branch the code and essentially run the DataPortal_Create code and return a new initialized BO. This pattern has worked fine for me. I can see where some people may not like this approach though. In that case you are back to Rocky's suggestions.

hurcane replied on Monday, September 18, 2006

I had the same kind of an issue recently, and I am using a separate factory object (e.g. UserFactory) for my object creation when I don't already know whether the data will exist. UserFactory is subclassed from ReadOnlyBase. UserFacotry contains a single read-only property, User, which returns a User object.

Inside the DataPortal_Fetch of the UserFactory, SQL is executed to check the existence of the ID. If the ID exists, the User object is instantiated and assigned to the backing field behing the User property. Otherwise, the User object is null/nothing.

The User object itself is designed as an editable root, except for how we code the factory methods and the constructors. Since the User object will always be instantiated inside the server-side data portal of the UserFactory object, it's more like a child object. In our case, the UserFactory fetches the data and passes a SafeDataReader to a Friend constructor on the User object. The User object has no factory methods. Of course, you could have factory methods (still with Friend scope), which is a little more consistent way to instantiate all business objects.