acess compiler/developer tools

  • Thread starter Thread starter Ardy
  • Start date Start date
A

Ardy

I understand that there are no compilers for access (2k) to
create a .exe?!?!? however, there is the developer kit
to create run time version?

if so, is there a performance gain in the runtime version?
compared to the developed copy?

thanks..
 
No. Deploying the runtime does not change your app in any way, it merely
installs a runtime version of Access (a copy of Access with the design
features disabled, so that it can be used to run existing Access
applications but not to create new ones). There is only one reason to deploy
a runtime, and that is that your users do not have Access. If they do, there
is no reason to deploy the runtime.
 
Not that I have ever noticed. The runtime version runs the same msaccess.exe
as the full version does. It just has a runtime switch added to the registry
and, thus, the normal menus and toolbars are not available -- along with a
host of other things.
 
Of course re-writing your application c++ and using a good compiler will NOT
CHANGE your performance by one bit anyway.

So, if you are looking for a performance fix to your applications, a good
compiler WILL NOT fix you problems. Any performance problems you have are
that of design, or perhaps data tables that are very large (ie: average
table size in the millions of records).

If you are talking about a multi-user appcltions with 4, 5 users, and very
small tables (say, 50,000 records), then that is nothing for JET based
applications, and any kind of delays should not be noticeable.

No doubt that VB has had a native compiler for what, two last versions?
However, when working with a database engine (JET, or sql server), the speed
of the code executing in ms-access is NOT relevant at all. On a cheap
computer, ms-access can easily execute 10 millions instructions in second
anyway. It is the waiting for everything else that causes things to be slow
(and those delays are exactly the same in c++ as they are in ms-access).
Ms-access is VERY rarely processor bound. It is the waiting for disk drive,
network bandwidth, supervisor code (OS code), speed of JET engine etc that
is the delay problems.

As mentioned, changing your access application to c++ will not speed up the
use of the database engine one bit.
 
Ardy said:
I understand that there are no compilers for access (2k) to
create a .exe?!?!? however, there is the developer kit
to create run time version?
Correct.

if so, is there a performance gain in the runtime version?
compared to the developed copy?
Click to expand...

No.

If you are having performance problems see the Access Performance FAQ
at my website.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
If you use the Developer Tool, and output this version, will the database still
open in the access window? Is it an option to open just a form and operate
without the Access parent window?
gm
 
Use of the runtime does not change your application in any way (except that
there are one or two features, such as the built-in filter-by-form feature,
that do not work with the runtime). If you want to hide the Access window,
there's an example of how to do that (regardless of whether you deploy a
runtime or not) at the following URL ...

http://www.mvps.org/access/api/api0019.htm
 
Brendan Reynolds (MVP) said:
Use of the runtime does not change your application in any way (except that
there are one or two features, such as the built-in filter-by-form feature,
that do not work with the runtime). If you want to hide the Access window,
there's an example of how to do that (regardless of whether you deploy a
runtime or not) at the following URL ...

http://www.mvps.org/access/api/api0019.htm
Click to expand...

Thanks for the url, I'd read once before there was a way to do this, but forgot
where I read it.
gm
 
Back
Top