Winform DataGridview incredibly slow compared to MS Access Grid

When I connect to an Oracle Database though ODBC with 100000 rows with MS ACCESS, I can see results instantly and go to the end of the records in 1 seconds.

Doing the same thing with ADO.NET and the Winform Datagridview is incredibly slow it takes dozens of seconds !!!

How开发者_运维百科 to get the same speed as MS Access Gridview ? I can't find any ready-to-use code to do so.

I suppose you're binding all rows to the DataGridview at once and it's the drawing that takes a long time.

If all you want is to display data, you can very easily implement Virtual Mode. All it takes is to implement the CellValueNeeded event. In Virtual Mode, the grid retreives only the rows needed for display.

It's also possible to implement all the operations a DataGridView can offer but it can take a lot of code.

Take a look at: Virtual Mode in the Windows Forms DataGridView Control

Thanks indeed it seems there is no simple way because ADO.NET didn't even include the features of the "old" ADO (I wonder what "progress" is finally :) ):

http://www.udaparts.com/devguide.htm

ADO.NET is designed to focus the needs of web applications with a completely disconnected model, which requires all of tables data are loaded into an "in-memory" database (a DataSet) before accessing these data. This model works well for web applications, but it does have a number of short comings that make it awkward to use for traditional desktop applications and middle tier components in many cases. In comparison to classical COM ADO/OLEDB technology, ADO.NET has following main short comings listed below:

a). It is very slow to access a large data table. ADO.NET can manage a small number of data records in disconnected model efficiently. However, it works very slow if the number of data records becomes large because ADO.NET requires loading these records into a DataSet object first and setting relationships among tables. The loading time becomes larger and larger when the number of records becomes larger and larger. It is this reason that leads to a large memory footprint in many cases.

b). ADO.NET supports sequential forward and read-only server cursor only. It works fine with web applications, but it becomes very awkward with developments for classical desktop and middle tier applications because these applications typically require data accessing mode is able to provide scrollable and updateable server cursors with bookmarks at least. Currently, ADO.NET is not able to provide these features. ADO.NET lacks many fundamental features that the previous COM ADO/OLEDB model provides. This is a huge problem especially for desktop application development.

Their component (http://www.udaparts.com/oledbpronet.htm) seems great except it's not free, hasn't someone developped something similar in Opensource ?

Found another solution http://www.infralution.com/virtualdata.html

Is ADO.NETs disconnected model making your simple desktop application seem like a major enterprise programming task?

Infralution's Virtual Data Objects (VDO) may be the solution you have been waiting for.

but still no opensource or free solution ?