Is Access VBA as fast as VB VBA? 
Author Message
 Is Access VBA as fast as VB VBA?

Is the Basic interpreter in Access 97 as fast as the Basic interpreter in
the most recent version of VB?

Also, does anyone happen to know if Access in Office 2000 will be available
as a native Alpha NT port?



Thu, 10 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?
Access VBA isn't as fast as compiled VB.  However, if your application is
dealing with MDB files, Access is as fast or faster than compiled VB simply
because the VBA code and the MDB file are in the same process space.  With
compiled VB, there is are at least two process transitions for every
reference to the MDB file, one to the file and one back from it.  Updates
take many more process transitions.

Note that both VB5 and VB6 compile native code (at least on the Intel
platforms).

Mike Ober.

Quote:

>Is the Basic interpreter in Access 97 as fast as the Basic interpreter in
>the most recent version of VB?



Fri, 11 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?
Mike,

Thanks for your informative reply.

Quote:

> Access VBA isn't as fast as compiled VB.  However, if your application is
> dealing with MDB files, Access is as fast or faster than compiled VB simply
> because the VBA code and the MDB file are in the same process space.

Yes, I do lots of stuff with MDB files.

Quote:
>  With
> compiled VB, there is are at least two process transitions for every
> reference to the MDB file, one to the file and one back from it.  Updates
> take many more process transitions.

I work with a lot of big recordsets. If one does a query and gets back, say,
1000 records then as one does a .MoveNext to each next record are there two
process transitions for each .MoveNext? Or were all the result records copied
back to the VB exe's process space in a single pair of process transitions when
the OpenRecordset was done?

If it isn't the default behavior then is there some way to force that copy of
all the result records when the initial query is done?

Quote:

> Note that both VB5 and VB6 compile native code (at least on the Intel
> platforms).

Does anyone know what is the case for the latest version of VB for Alpha?
Quote:

> Mike Ober.


> >Is the Basic interpreter in Access 97 as fast as the Basic interpreter in
> >the most recent version of VB?



Fri, 11 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?

says...
Quote:
> Access VBA isn't as fast as compiled VB.  However, if your application is
> dealing with MDB files, Access is as fast or faster than compiled VB simply
> because the VBA code and the MDB file are in the same process space.  With
> compiled VB, there is are at least two process transitions for every
> reference to the MDB file, one to the file and one back from it.  Updates
> take many more process transitions.

FWIW, Access VBA (if you've ensured that your code is compiled) should be
exactly the same speed as VB apps compiled to p-code. It's all the same
thing. OTOH, if you compile to native code in VB5 or VB6, your code will
definitely run faster.

But, DAO is an activeX DLL, which means that calling DAO from VB5 or VB6
is an in-process call, just as it is from within Access. THat means that
using DAO from VB and using DAO from Access are exactly the same thing,
with the same overhead.

The real issue is that when working with databases, code speed isn't the
issue -- it's swamped by disk speed. It just doesn't matter how fast your
code is running, since you're accessing the disk often, and that's
hundreds (or more) of times slower than memory access. -- Ken



Sat, 12 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?
Ken,

Thanks for the correction/update on my older information about accessing MDB
files.  Also, I agree that to an extent, disk I/O is the limiting factor.
However, improper design and code will always kill performance.  Proper
design (in any language) is essential for good performance.  I changed how I
was using Replication IDs in an application and turned a 2-3 hour run into a
sub-15 minute run on the same hardware/OS combination.

One other comment - Access is definitely easier to start working with, but
the full blown VB has more capabilities for an experienced developer.

Mike Ober.

Quote:


>> Access VBA isn't as fast as compiled VB.  However, if your application is
>> dealing with MDB files, Access is as fast or faster than compiled VB
simply
>> because the VBA code and the MDB file are in the same process space.
With
>> compiled VB, there is are at least two process transitions for every
>> reference to the MDB file, one to the file and one back from it.  Updates
>> take many more process transitions.

>FWIW, Access VBA (if you've ensured that your code is compiled) should be
>exactly the same speed as VB apps compiled to p-code. It's all the same
>thing. OTOH, if you compile to native code in VB5 or VB6, your code will
>definitely run faster.

>But, DAO is an activeX DLL, which means that calling DAO from VB5 or VB6
>is an in-process call, just as it is from within Access. THat means that
>using DAO from VB and using DAO from Access are exactly the same thing,
>with the same overhead.

>The real issue is that when working with databases, code speed isn't the
>issue -- it's swamped by disk speed. It just doesn't matter how fast your
>code is running, since you're accessing the disk often, and that's
>hundreds (or more) of times slower than memory access. -- Ken



Sat, 12 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?

says...
Quote:
> One other comment - Access is definitely easier to start working with, but
> the full blown VB has more capabilities for an experienced developer.

Depends on what you need. I spend most of my time right now in VB, just
'cause that's where my work is, but there's little that VB can do that
Access cannot, and that gap will narrow in the next release of Office.
OTOH, the forms package in VB will always be a little more "sturdy"... --
Ken


Sat, 12 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?

Quote:


> says...
> > One other comment - Access is definitely easier to start working with, but
> > the full blown VB has more capabilities for an experienced developer.

> Depends on what you need. I spend most of my time right now in VB, just
> 'cause that's where my work is, but there's little that VB can do that
> Access cannot, and that gap will narrow in the next release of Office.
> OTOH, the forms package in VB will always be a little more "sturdy"... --
> Ken

Hi Ken,

For those of us that are still pondering the move to VB, could you
elaborate on "sturdy" here - is this serious ("a sturdy log cabin") -
meaning they perform better and are more stable (how?), or
tongue-in-cheek ("a sturdy gal") - meaning they're a bit clunky and
cumbersome.

Keri



Sun, 13 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?

Quote:
> For those of us that are still pondering the move to VB, could you
> elaborate on "sturdy" here - is this serious ("a sturdy log cabin") -
> meaning they perform better and are more stable (how?), or
> tongue-in-cheek ("a sturdy gal") - meaning they're a bit clunky and
> cumbersome.

My intent was that VB forms allow you to retrieve window handles for
controls, and thereby allow you to do things you simply can't do on
Access forms. Their event model is different than Access', and in some
ways better, some ways worse. You really miss the
BeforeUpdate/AfterUpdate thing, but I love the QUeryUnload and Validate
events. -- Ken


Sun, 13 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?
Hi,

One thing I like for VB forms, it is that they allow you to draw EASILY on
them. If you have a GIS (Geographical Information System), Access is great
as a database tools supplier, and really help maintaining the data in
multi-user environment, but its interface, its forms, they are horrible when
it is time to move the tiny little symbols all over the geographical map.
There is a couple of things I don't like in VB, but that one, is one I like
very much: graphical capabilities. When will Access have a minimal GIS
support? I don't quite follow the MS logic. They present a Tera-bytes
database supported by MS SQL7 (and thus indirectly by Access 2000 too when
it will be released) allowing you to get a satellite view of your "home",
if you wish, but, man, what do you do next with that picture?  Access is
really too "traditional data" oriented, in my opinion, and its forms reflect
that.

Vanderghast, Access MVP.

Quote:


>> For those of us that are still pondering the move to VB, could you
>> elaborate on "sturdy" here - is this serious ("a sturdy log cabin") -
>> meaning they perform better and are more stable (how?), or
>> tongue-in-cheek ("a sturdy gal") - meaning they're a bit clunky and
>> cumbersome.

>My intent was that VB forms allow you to retrieve window handles for
>controls, and thereby allow you to do things you simply can't do on
>Access forms. Their event model is different than Access', and in some
>ways better, some ways worse. You really miss the
>BeforeUpdate/AfterUpdate thing, but I love the QUeryUnload and Validate
>events. -- Ken



Mon, 14 May 2001 03:00:00 GMT  
 Is Access VBA as fast as VB VBA?
Michel,

Have you noticed that ESRI (Arc Info) is a very visible "partner" at
many MS events (at least here in the US).  They (ESRI) have also moved
to a VBA interface.  It reminds me in a way of the relationship between
Visio and MS, which (in my observation) is one of relatively peaceful
co-existence.  

However, I've also heard that MS plans to move heavily into the GIS
market; I don't know, though, if this is on the high-end, or more on the
end-user level.

Keri Hardwick

Quote:

> Hi,

> One thing I like for VB forms, it is that they allow you to draw EASILY on
> them. If you have a GIS (Geographical Information System), Access is great
> as a database tools supplier, and really help maintaining the data in
> multi-user environment, but its interface, its forms, they are horrible when
> it is time to move the tiny little symbols all over the geographical map.
> There is a couple of things I don't like in VB, but that one, is one I like
> very much: graphical capabilities. When will Access have a minimal GIS
> support? I don't quite follow the MS logic. They present a Tera-bytes
> database supported by MS SQL7 (and thus indirectly by Access 2000 too when
> it will be released) allowing you to get a satellite view of your "home",
> if you wish, but, man, what do you do next with that picture?  Access is
> really too "traditional data" oriented, in my opinion, and its forms reflect
> that.

> Vanderghast, Access MVP.



> >> For those of us that are still pondering the move to VB, could you
> >> elaborate on "sturdy" here - is this serious ("a sturdy log cabin") -
> >> meaning they perform better and are more stable (how?), or
> >> tongue-in-cheek ("a sturdy gal") - meaning they're a bit clunky and
> >> cumbersome.

> >My intent was that VB forms allow you to retrieve window handles for
> >controls, and thereby allow you to do things you simply can't do on
> >Access forms. Their event model is different than Access', and in some
> >ways better, some ways worse. You really miss the
> >BeforeUpdate/AfterUpdate thing, but I love the QUeryUnload and Validate
> >events. -- Ken



Fri, 18 May 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Access 97 VBA v Access 2K VBA - different ?

2. Access 2000 VBA Handbook vis a vis Access 97 VBA Handbook

3. Access VBA Calling MSWord/Excel VBA?

4. VBA Analysis Tookpack- Excel In Access VBA

5. ACCESS VBA - why different from other vba?

6. vba access vs vba excel (alguien sabe?)

7. How to access Office VBA from Outlook VBA

8. Exec. Word VBA Function From Access using VBA

9. Differences between VB amd VBA and VBA Education

10. accessing access xp vba from vb

11. am I ready for vba ?

12. Am I too stupid to program VBA?

 

 
Powered by phpBB® Forum Software