Disabled Recordset

Someone I know wants to use diconnected recordsets in an app. It seems to me that if I have an ORM tool, it really won't even need to touch the disabled recordsets. As I understand it with the ORM, the ORM takes care of not hugging connections for an unnecessarily long time, deciding the need for a disconnected recordset. Is there an instance where you want to use the disabled recordset anyway?

0


source to share


2 answers


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

This may not be exactly what you meant, but it is the correct answer to your question, such as an example of when you still want to use a disabled recordset even if you have an ORM.



** Similary, ADO Parametric objects are a common alternative to the Variant type in that, unlike the built-in VB types, they can be either strong data or nullable.

+1


source


I would consider using a recordset in small gather and forget applications or when you have simple reporting needs such as a read-only grid view.

This includes any application that makes you feel like the fastest thing you can do and you see no reason why it will change later.



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

But of course it's still used there.

0


source







All Articles