Disconnected Recordset

Question

Someone I know wants to use diconnected recordsets in an application. To me it sounds like if I have a ORM tool there would really be no need to even touch disconnected recordsets. The way I understand it with ORM the ORM takes care of not hugging connections for unnecessarily long amounts of time, solving the need for a disconnected recordset. Is there an instance in which you would still want to use a disconnected recordset?

Answer 1

A fabricated ADO recordset can be a good choice of container object for data, as an alternative to a VBA Type (struct), Collection, Dictionary, etc i.e. strongly data typed nullable fields** with built-in support for filtering, sorting, searching, output to formatted text/xml/array, paging , cloning, etc. A fabricated ADO recordset is disconnected by definition.

Perhaps this isn't quite what you had in mind but it is a valid answer to your question i.e. an example of when you would still want to use a disconnected recordset, even though you have an ORM.

** Similary, ADO Parameter objects are a usual alternative for the Variant type in that, unlike VB intrinsic types, they can be both strongly data typed and nullable.

Answer 2

I'd consider using a recordset in small "assemble and forget" applications or when you have simple reporting needs like read-only grid views.

That includes any application where it feels like the quickest thing you can do, and you don't see a reason it will change later on.

However, if you are going to build a slightly advanced, maintainable, robust application, with business logic and the like, don't go with recordsets.

But sure, there's still use for it..