Thanks for the update imagemaker. I did code the public properties in my info class using the get and set methods, but some of the data simply did not get populated. If I understand what you are saying, and correct me if I am wrong here; but you are saying that I need to have my properties match the field names that the stored procedure returns and that they are case sensitive. Is that right?

I haven't gone back and made my properties the same case as my field names - I like capitolized properties without underscores (Ex: NewsId, ModuleId). My company has a database design procedure that requires underscores in field names (Ex: news_ID, module_ID).

If this is the case; I wrongfully assumed that CBO.FillCollection would use the initializer constructor where the compiler would choose the best constructor using polymorphism and reflection (take a look at my second constructor). It would also explain how some of my data got populated and some data didn't. The single name fields (Content, Title, and Heading) were all populated, while my ID, DateTime, and the other multinamed fields were not.

Anyhoo, assuming all this is correct, the property names are my problem and knowing is half the battle. I think I understand the issue well enough to make ends meet now. I can either alias the field names in my stored procedures, or go and change all my code.

Thanks!

---

Cheers!
John Valentine

Thanks for the info cnurse. This is inline with what I was saying before. You are really only creating another constructor that takes an IDataReader as an argument... .NET can use polymorphism to determine which constructor to run, and you can throw the overhead associated with reflection out the window while still using the common business objects. Most people tend to generate their modules with CodeSmith or with the new DNN templates anyway. It would be simple to have this model implemented in a template update after changing the common business objects to support this method as well as reflection.

My own Info class has this exact same code (only in C# syntax):

public WyleNewsInfo(IDataReader dr) {
this.NewsId = Convert.ToInt32(dr["news_Id"]);
this.StatusId = Convert.ToInt32(dr["status_Id"]);
this.ModuleId = Convert.ToInt32(dr["module_Id"]);
this.Title = dr["title"].ToString();
this.DateEntered = Convert.ToDateTime(dr["date_Entered"]);
this.CreatedBy = dr["created_By"].ToString();
this.ExpirationDate = Convert.ToDateTime(dr["expiration_Date"]);
this.Content = dr["content"].ToString();
this.EditedDate = Convert.ToDateTime(dr["edited_Date"]);
this.EditedBy = dr["edited_By"].ToString();
this.Attachment = dr["attachment"].ToString();
this.Url = dr["url"].ToString();
this.Heading = dr["heading"].ToString();
this.TimesAccessed = dr["times_Accessed"].ToString();
this.LocationId = Convert.ToInt32(dr["location_Id"]);
this.GroupId = Convert.ToInt32(dr["group_Id"]);
}

It is exactly how I had my code working before. I see in your code you are looking for dr.Read() however if you were to put it in a while loop you can merge your two functions. Assuming you have your dr instanced:

List articles = new List();
while(dr.Read()) {
articles.Add(new WyleNewsInfo(dr));
}

return articles; // who cares if it returns an empty List. A datasource can handle the nill and display nothing without my having to write code to handle error trapping.


The basic thing that I see in your hydration code is that you are breaking away from the basic data encapsulation rules by moving your hydration code (which is really a constructor) out of your class an putting it into the business layer. Classes should always be self instantiating (hydrating).

Beyond that, I am happy to know that I was beating down the right path as most everyone else. Thanks for your contributions to DNN. I really do appreciate all the work you folks do!

Cheers!

---

Cheers!
John Valentine