Hey Trent,
I respectfully disagree that this is not really an issue I do agree that this is not a NOTICEABLE issue for most day to day use's of business object's. I would also like to clarify that The bottleneck is with setting field values in a BO vs. a ADO datatable ,NOT on the adding of rows or the saving of rows.(BTW I do use Bulk Copy in instances where I am doing mass inserts of records but it doesn’t change this issue).

As an example programmatically SETTING the values of 100 fields in 1 data row takes .002 seconds via Strong Typed BO properties and .0000000000 seconds via weak typed ado, probably not noticeable. However setting the same values for the same 100 fields but for 1000  data rows then takes 7.64 seconds vs .03 seconds and that IS a noticeable difference.

I realize I can refactor my code to use weak typing and directly reference the businessobject's underlying datatable to increase performance by bypassing whatever underlying handler is mucking up the waters and I have done this in some places where I need the performance and was unable to wait for it to be resolved.
Really the long and short of it is that I am using a business object to programmatically set multiple values for somewhat large tables with large recordset’s. Although this usage may not be the norm ,I feel it is reasonable to expect a business object to perform somewhat on par with a datatable?

 
I realize that whatever is causing the issue is in a sticky spot and will take you guys more time to resolve and I appreciate the time and effort that it takes to get to it. I just wanted to clarify what exactly the issue is, and to simply re-iterate that this is an issue that affects my business processes negatively and let you know I appreciate whatever you can do to resolve it .

Thanks Man,

Paul

Well, I am not sure that it is actually an issue. From reading through the post, you are dealing with large numbers of records in a single BO. If you are trying to do mass updates, then the SqlBulkCopy is a great way to dump tons of records into a table and totally sidetracking the strong-typing and data verification.



That being said, I have not had a chance to put this through a code tracing tool to see where your exact bottleneck may be. Most like there is an event being raised and handled. I will take another look when I get my head above water.

Trent,

I recently updated to the latest version of SF and was unable to tell if this issue was resolved ?

Thanks

Paul

Hi Paul,



I agree with Keith about SQLBulkCopy, in fact in this thread you can see how Keith's sample code helped me in this regard.

Edhy Rijo

Hi Paul,

   Darn, I was in such a hurry to tell that anecdote that I didn't read your post carefully. That'll learn me...

Les

I am very interested in your findings, I found this a long time ago and honestly just figured it was the way it was, anything over 20k records (ballpark) I have been using SQLBulkCopy to get speed on the commit.

Keith Chisarik

Hi Les,

I think there is a misunderstanding, I am not trying to use a listview with a large recordset 

I am bulk importing records from foxpro to a sql database. The issue I am having is that setting the values on the destination business object via the strong typed property takes a good bit longer than setting the values on a plain jane datatable.

Hi Paul,

   What's the old joke? A guy says "Doctor, it hurts when I do this" and smacks his head. Doctor says "Then don't do it..."

   Back in the heyday of FoxPro, I wrote an article very similar to your comment about the listboxes in the "two-column mover" control created by Alan Griver, who is now in charge of languages at MS. I was able to load a 50,000-line listbox must faster than his method did, using arrays. His answer was "why do you need 50,000 items in a listbox?". I had to admit that he was right.

   There's probably a way to speed up listview loading internally from a business object, but maybe a BrowseDialog will give your users a more manageable way of filtering and selecting records than would a ListView. That's what I ended up doing. By the time my users got to the two-column-mover, they were looking at only a few hundred records, having already filtered out what they weren't interested in.

Les

Thanks Trent.

For the most part the import routine that this affect's runs after hours unless there is some type of exception that would require a manual rerun. So rather than refactor the mapping methods to use a datatable I will leave it as is for now as I do have some other stuff going on that I might break. So it is not a life or death issue for me but I did want to find out what was going on, and obviously resolve it.

I understand 100% that this will not be a "quick" fix as the underlying datatable events have to be one of the worms at the bottom of the business object can.

Appreciate ya,

Paul  

One more thought...the main thing here is that before we make any changes, we are going to have to totally understand the bottleneck and make sure that any change made doesn't break something else as this would be a low level change. Thus the time necessary to diagnose needs to be allocated prior to making any change.