> > For example: For the iter data, you could store the rows offset. In > > PostgreSQL and SQLite, using the row OID works great as it is the > > fastest way to access any record. However, using a system that allows > > you to determine the next rows Iter data without a new query is > > probably a good idea. If I remember correctly, I got my best > > performance by mixing the two ideas; Batching queries to get the next > > 10 rows OIDs.
I'd hope that any Gtk# data-binding would be binding to an ADO.Net DataSet/DataTable and not dealing with any specific providers. DataTable provides a primary key property, IMO, nothing should depend on anything except that; that and the ChildRelations / ParentRelations seem adequate to automatically fill a TreeView; although I still doubt anyone [in practice] is actually using a TreeView in such a straight-forward way - Entities, Labels, and ComboBoxs probably, but TreeViews I see are usually of some kind of composite/tabulated data.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
