C1 Community

I have many controls bound to tableviews within my dataset so I need to streamline as much as possible.

Calling the Update method on a dataset refreshes all tableviews in the dataset (even those without modifications to their corresponding tables) which then causes the controls to be notified that they need to refresh their contents.

So - I have some code where I need to call Update multiple times and in order to reduce overhead I'd like to:

1. set SuppressNotifications = True

2. call Update

3. make other changes to dataset

4. call Update

5. set SuppressNotifications = False

My Question: After I reset SuppressNotifications, do I just loop through the Tableviews for the dataset and call the C1DataTable's Refresh method?

 

You have to call the Refresh() method for the each the TableView in your dataset. Resetting the SuppressNotifications property doesn't automatically refreshes data bound controls. Do you observe any problems with refreshing controls?

Thanks Andrey! 

Yes-

It must be important as to the order I call for the tables to refresh.

If I just use the order as determined by the collection, tableview 'Item' gets called.

Item is a very large list of products. It is 1 of 4 tables in a composite table. Tracing, refresh on Item results in the DataSet triggering CurrentRowChanged event on 'Item' and then the composite tableview 'ProposalDetails' which must then trigger a ListChanged event because the FlexGrid bound to ProposalDetails gets an AfterDataRefresh event which I use to format the grid. The grid's datasource is a C1DataView based on 'ProposalDetails'. This is where the problem comes in. I found that the columns in the grid's row do not have any values at this point.

Probably the result of 'ProposalDetails' tableview not getting refreshed prior to Item???

This brings up a related question. I'm very concerned about the performance of my application. Although the database Update method happens very quickly, the resulting update of all controls is not. Particularly bothersome is that whenever I call Update, only a few tables need updated but all tableviews in the dataset get rebuilt and thus databound controls updated. Do you have any suggestions? I have already moved some tables to an alternate dataset.

Is there a property(s) on the table that controls whether the tableview needs refreshed? If the table is Readonly, no Delete, no AddNew, you'd think that would be enough to know the tableview doesn't need recreated...but I'm probably oversimplifying.

 

C1Data refreshes simple tables, then rebuilds table views that include the refreshed tables.
In the Schema Designer you may set the UpdateRefreshMode property to Never for simple
tables those shouldn't be refreshed after Update. You may even set the UpdateRefreshMode
to Never for all simple tables. Then you will refresh data using the Fill method (only).

Regards,

-Andrey

Although it makes sense, setting UpdateRefreshMode to Never doesn't seem to control whether the TableViews get rebuilt or not after Update. It must just control whether it issues a SELECT to retrieve the current values from the database.

I set UpdateRefreshMode=Never for the simple table 'Item'.

In my program, no changes were made to row(s) for table 'Item'.

After rebuilding, in my debug session I compared the instance of the 1st row of the TableView for 'Item' before/after the Update - they were not the same.

I did the same for the simple table, they were not the same either although they DID refer to the same StorageDataRow. I REALLY don't understand why the C1DataRow(s) for the simple table changes. (But I guess that would explain why the TableView gets rebuilt) Could it be because I'm using a Data Library???

Does this make sense?

Andrey

Wow- Thanks so much! I've been really concerned about this. I'll let you know what I find.

Thanks,

Teresa

Thanks, the performance improvement is huge - the TableView rows are not re-created thus there are no DataSet.CurrentRowChanged events triggered and the data bound components do not need refreshed.

The only thing I wonder about is that if something is changed in a row due to a refreshed value from the database or say a change in the AfterUpdateRow event, there is still no CurrentRowChanged triggered.

But for my purpose, this patch works great for me.

I have two questions:

1. Can you do the same for RejectChanges? It does the same thing the Update used to, many many CurrentRowChanged events based on TableViews/Relationships. It takes 6 seconds in my application whereas the Update now takes less than 1 and it is all due to overhead updating all data bound components.

2. Will this change be rolled into a future release? I'm fairly close to delivering my application and would like to ultimately use a version that has passed formal validation.

Also - this patch also fixed my other dilemma where I was losing my ExtendedData object due to Update()

Thanks Again

Hi,

There was a bug in the previous build, sorry. The performance
improvement shouldn't be so huge. Please download and try
the updated build:

http://download3.componentone.com/pub/Net/c1data/misc/C1DataObjects_2.0.20082.202.zip

> 1. Can you do the same for RejectChanges?

Yes, the RejectChanges method has also been optimized in build 202.

> 2. Will this change be rolled into a future release? I'm fairly close to
> delivering my application and would like to ultimately use a version
> that has passed formal validation.

I don't know much about the current state of the forthcoming release.
Hopefully, it is not frozen yet and these changes can be included into
the release.

Regards,

-Andrey

Andrey,

The update time is now 9 seconds for 1 record modified in 3 tables. That is an overhead of over 8 seconds probably just for handling the data bound controls.

I've added a listing of diagnostic messages that I printed out during Update. Most suspicious are the lines printed from the DataSet.CurrentRowChanged event - it triggers many many times redundantly during the Update. Does this look right?

The update time is better than originally because not all the tableViews are rebuilt but 9 seconds is still a long time - Note I timed the Update without all the CurrentRowChanged messages.

Thanks,

Teresa

Hi Teresa,

I have now suppressed change notifications during the longest process
of recreating the tableViews. Please try the next build:

http://download3.componentone.com/pub/Net/c1data/misc/C1DataObjects_2.0.20082.203.zip

Hopefully, it works better...

Regards,

-Andrey

Andrey,

Sorry for the delay - I've been busy evaluating my application with a performance profiler.

Version .203 works great, my update time is now about 3 seconds. Thanks so much!

While profiling my application I found another couple of DataObject gotchas:

1) My main window creates a C1DataSet and fills it BEFORE binding to controls. It was taking about 25 seconds for the fill method to return. From timing Before/AfterFetch I noticed the actual data was loaded in about 3 seconds. I found that once again the DataSet.CurrentRowChanged event was triggered many (11,000+) times after the data was loaded and before fill returned. I worked around this by commenting out the assignment of BindingContextCtrl to the dataset in the designer code and then assigning it after the fill. Works like a charm. The Fill now takes just over 3 seconds.

2) In a sub-form and various userControls I use on the main window, I create a temporary c1dataset to use for design. I found that for some reason that caused a problem while doing simple databinding when the userControl or Form was instantiated. One DataBinding.Add statement in each of these cases took about 20 seconds! It seemed to be the first control on some type of container. (I thought at first it was caused by use of the C1DockingTab and so posted a message there). In order to get around this I moved all databinding code from the designer code to a method I call after InitializeComponent and removed the temporary dataset.

If you see any problem with my approaches please let me know.

Thanks,

Teresa

Hi Teresa,

Thank you for reporting issues. I'll see into both problems at the first opportunity.

Regards,

-Andrey

Andrey, 

After testing with the new version a bit more I found a problem I reported back in August 2007 which is why I was still using an older version of C1Data.

The technical support issue reported was: "There is no proposed data to access" error ISSUE=1734 PROJ=42. I tried updates given to me by technical support but in the last correspondence with techincal support I reported that I get a:

No Current Data error after I create a new record via AddNew and then try to set a field programmatically. This issue was never resolved.

This issue is specific to creating a new record for a composite table. I've attached a simple sample solution which demonstrates the problem. It has two datagrids, both attached to two different composite tables. Adding a record and setting fields to one of the composite tables works fine, the other results in the 'No Current Data' error.

Note for the composite table that causes the error, if I remove the 3rd simple table (ProposalLineItems) from the composite table, there is no error.

Is this easily fixable or do you know of a work around?

Thanks,

Teresa

Hi Teresa,

This is a very difficult problem. I'll try to find out the source
of this bug but can't promise you anything.

Regards,

-Andrey