Are recordsets faster than the Data Control? 2

[DavidJWhite]

Hello everyone.

I'm working on a DBMS that accesses an Access 97 Database from a VB (5) front-end. About 70 tables, 500 fields. Very robust front-end required, about 50,000 lines.

I get much of my data via a series of Data Controls. I would like any speed enhancements, and was wondering if using the DAO set rs = OpenRecordSet ... etc stuff would be faster than accessing the Data Controls? I cannot find any discussion on speed comparisons.

Any thoughts would be appreciated.
Thanks in advance.

 

[TomKane]

I'm not sure about whether it's faster (instinct tells me it is) but it's certainly more flexible and it means you can build applications that don't need cumbersome data controls all over the place - particularly if you're building dll's and stuff like that

 

[aata]

yes, as far as i know, it's faster. when we deal with a lot of records, i've seen it to work more efficiently and faster than data controls.

 

[DavidJWhite]

Thanks, Tom and Teresa,

my instinct told me it ought to be quicker - a recordset must have a much smaller footprint than a GUI control. Good to have the feedback though. Does anyone have any comparison statistics?

 

[MichaelRed]

I 'wonder' why you would use VB as a front end to an Ms. A. db? If the records are generally in Ms. A. it would SEEM like there is little advantage to the use of VB for the 'front end', just a lot of additional 'sttuuufffffff' to deal with the popuilation of controls and updating of recordsets. Ms. A. normally uses bound forms - which 'act like' the datacontrol in relating the fields to the record.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[DavidJWhite]

Dear MichaelRed,

The reason I used a VB front-end is because of the client specification - they wanted a high level of security, so that skilled users cannot modify the structure and data apart from via strict validated front-ends. Additionally, user skill level varies enormously, and low-IT users needed a very robust UI. Various delivery sites have differing views of the same data structure, and there is a requirement to be able to run all variants simultaneously across the country. The client also runs different Access & Windows versions across the country. The system requirements and goalposts change on a regular basis as a result of external contractual requirements, so easy modification and updating was required.

I concluded that VB gave me the flexibility, security, robustness, maintainability and modifiability that was required. An exe would run faster, and can be updated without updating the base DB. Likewise a separate exe can easily modify the exisiting DB structure and data.

I wish I'd developed it in C++ now!