# Large Datasets: Virtual Mode ## Content As mentioned in the [Large Datasets: Paging](/componentone/docs/win/online-datasource/DesignTimeFeatures/LargeDatasetsPaging) topic, [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) has an even better solution than paging for dealing with large data and large numbers of rows. What if using large datasets with thousands, or even millions, of rows was no longer a problem? What if you could use the same controls to display massive datasets as you would for smaller datasets, with no paging, no code changes, and all by setting one Boolean property? With [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) you can, thanks to the magical **VirtualMode** property. To implement virtual mode, follow these steps: 1. Using the project we created to demonstrate [Large Datasets: Paging](/componentone/docs/win/online-datasource/DesignTimeFeatures/LargeDatasetsPaging), add a new form with a [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) component using the same **ContextType** as before. Note that you can make this the startup form to save time when you run the project. 2. Create a **ViewSource** in the **ViewSourceCollection** editor. Use the largest table in our sample database: _Order\_Details_. 3. Set the **VirtualMode** property to _Managed_. Another possible value is _Unmanaged_, but that is an advanced option that should be used with caution and only when necessary. The _Managed_ option means that getting data from the server is managed by a grid control. With the _Managed_ option, [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) supports C1FlexGrid and Microsoft DataGridView. It is optimized for performance with those specific grid controls. The _Unmanaged_ option means that virtual mode is not driven by a specific control, will work with any bound controls but is subject to some limitations described [here](/componentone/docs/win/online-datasource/ProgrammingGuide/VirtualMode/UnmanagedVirtualModeLimitations). 4. Add a **DataGrid** to the form and set its **DataSource** property to the [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) and its **DataMember** property to _Order\_Details_. 5. Now, since we selected the _Managed_ option, we need to specify which grid control is driving the data. Select the grid in the designer and find the property called "**ControlHandler on c1DataSource1**" in the Properties window, as shown in the following picture: ![](https://cdn.mescius.io/document-site-files/images/94bcede7-c342-4bf9-97a8-95fb8706d41c/large_datasets-_virtual_mode_files/image001.png) This is an extender property and will be available only if there is a [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) component on the form. Set the **VirtualMode** property there to _True_. 6. Save, build and run the application. You’ll see nothing earth-shattering, simply a grid you can navigate, scroll and modify as you see fit. It looks and behaves like any conventional data grid, which is exactly the point. You can use large datasets without the drawbacks of paging and without code. And as an added benefit, you can use any GUI control you like so long as it has a DataSource property. This example uses a relatively modest-sized dataset, but [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) running in virtual mode would be just as responsive with a much larger dataset; it does not depend on the number of rows. To further prove the point, look at the **OrdersDemo** sample installed with this product. The sample uses a larger database, with roughly 65,000 additional rows, but the responsiveness is the same as our example here. Again, it does not depend on the number of rows in the dataset. How does this magic work? It works much like paging, only hiding its inner workings from the GUI controls, with paging occurring under the hood. The GUI controls see the data as if it is fetched to the client and ready for them. When GUI controls request data, [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html), or **ClientViewSource** if it is used in code without a [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) control, first checks whether it can serve the data from memory, from the same client-side cache it uses for all features. If it can’t find it in memory, it transparently fetches the required data from the server. As with other features using the client-side cache, [C1DataSource](/componentone/api/win/online-datasource/dotnet-framework-api/C1.Win.Data.Entity.4.8/C1.Win.Data.Entities.C1DataSource.html) does not store the fetched data indefinitely, which would be a memory leak. It knows which parts of the data are needed for serving the GUI controls and which parts should be kept because they are modified or related to modified parts, and so on. It releases old, unnecessary parts of data as needed. No code is required and any GUI controls can be used.