Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
265
Populating a UltraDataSource and best practices
posted

Hi, 

   I have a confusion over the timing of populating an UltraDataSource.

What is the exact purpose or extra that a UltraDataSource provides over the other collections like DataSets, DataTables or ValueLists? Simply stating, why would anyone need an UltraDataSource, when one can simply bind these other objects to the ultragrid?

What is the difference between populating a ultradatasource in a custom method call and in a InitializeDataRowCollection? What is the difference between populating the ultradatasource in a InitializeDataRowCollection versus IntializeDataRow? 

What do the ISupportInitialize calls for BeginInit and EndInit implemented by UltraDataSource do in specific? 

What is the most efficient way to populate an ultradatasource? Does Ultradatasource allow being accessed from a back ground thread? 

Thanks, 

Bhushan. 

Parents
No Data
Reply
  • 469350
    Suggested Answer
    Offline posted

    Hi Bushan,

    There are a number of different situations in which you might want to use an UltraDataSource.

    If you are using a data source like SQL Server, then a DataSet/DataTable is designed to allow you to retrieve and update your data to the back end.

    But maybe you have a very simple app where you need a grid to display some local data to the user and don't want to set up a complex DataSet/DataTable. You could use an UltraDataSource in this case and define the data right in code.

    You could also do this with more complex data in a case where you don't need relational data. For example, if you have data where the parent are child rows are simply hard-coded and don't change, as opposed to relational data where the parent and child data are based on a value within the data. This also make the UltraDataSource a little faster when working with hierarchical data, since it doesn't have to calculate the relationships.

    Bhushan Inamdar said:
    What is the difference between populating a ultradatasource in a custom method call and in a InitializeDataRowCollection? What is the difference between populating the ultradatasource in a InitializeDataRowCollection versus IntializeDataRow? 

    These events are for loading data on-demand. This is for efficiency and performance where you have a large set of data to show and you don't want to load it all at once. There are samples included with the suite called the "Virtual Mode sample" which demonstrates using the UltraDataSource to show 1 million rows in an UltraWinGrid in an efficient way without loading all of the data up front.

    Bhushan Inamdar said:
    What do the ISupportInitialize calls for BeginInit and EndInit implemented by UltraDataSource do in specific? 

    ISupportInitialize is for design-time serialization and deserialization. It''s not really something you need to worry about, it's all handled by the designer.

    Bhushan Inamdar said:
    What is the most efficient way to populate an ultradatasource? Does Ultradatasource allow being accessed from a back ground thread? 

    Using threading with DataBinding is generally not a good idea. When you use multiple threads, you need to marshal the communucation between those threads and in the case of data binding, you are not in control of that communication. So while it might, in theory, be possible to populate an UltraDataSource on a separate thread, you cannot do it while it's bound to a control in the UI, which would probably defeat the purpose of using another thread, so there wouldn't be much point in it.

    The most efficient way depends a lot on what your requirements are and what your app needs to do. As I mentioned you can use load-on-demand if you can efficiently load your data from wherever it's stored a piece at a time in an efficient way. Generally speaking, I think the most common use case is to just populate the data up front - which will work fine as long as your data set is of a reasonable size.

Children