Porting to VB6

[Peter]

I have an application written in Access 2000 that I
distribute to a number of organisations who use it on a
variety of platforms, ranging from a P75 running Windows
95 to modern XP machines. It has about 40 forms and
reports and 25K lines of VBA.

I would like to distribute it over the Internet, but I
have to send Access Runtime with the application. This
makes the distributable much too big to download over an
ordinary modem, which is all most of my customers have.
So I am thinking of reworking it in pure VB6, using an
Access (Jet) database connected through ADO.

I have two questions that I wonder if anybody can help me
with.

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

If I am going to all this trouble, would it be better to
move to VB.Net? Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework. If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

Any comments and suggestions would be much appreciated,
as would any pointers to useful articles or books.

 

[Arvin Meyer]

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

No, not without the runtime

If I am going to all this trouble, would it be better to
move to VB.Net? Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework. If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

You'll have an even bigger problem. There are different versions of the
VB.NET Framework, that vary in size from 20 to 30 MB, none of which will run
on the weaker machines. They don't all run smoothly side by side. They'll
need to be multiple versions on some machines which may break existing
applications.

You have 2 viable options if you don't want to distribute the runtimes. VB6,
or an ASP application. Both of them can use JET databases although the ASP
application might have other difficulties (can't take too many hits, needs
an IIS server, you can't easily secure your code)
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Sandra Daigle]

Answers inline:

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

You will have to port these to VB forms and reports. Access uses an entirely
different object model.

If I am going to all this trouble, would it be better to
move to VB.Net?

Probably - I see no indication that VB.Net is going away. If I had to do
something similar I would take the time to learn VB.Net.

Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework.

Since I have not done much with VB.Net I can't fully answer this question
except to say that when you move to VB.Net you will be giving up the
datacentric convenience of using Access forms and reports. I would assume
that a well written application should perform well in VB.Net but I don't
have the experience to confirm this.

If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

You will have to send the .net framework. The 1.1 framework is about 70MB. I
think the Access XP runtime version is approximately 120 Meg.

 

[Norman Yuan]

Just a bit clarification what Arvin & Sandra have said.

..Net ( either you use VB.NET or C#, no big difference) framework is a must
to run .NET App. It is about 25 to 26 MB (while .NET SDK is over 100MB and
only needed when you want to develop .NET app). Also, .NET app only runs on
Win98SE or later and WIN2K later is recommended (some advanced features of
..NET are not available in Win98/Win ME). Currently there are two versions of
..NET framework: 1.0 and 1.1. Version 1.1 is back compatible, meaning app
writteh in 1.0 can run under 1.1, and you also can have two verion installed
side by side and configure your .NET app to run under specific version of
framework.

Also, VB.NET is significantly different from VB6. While porting Access app
to VB6 could result in big portion of rewriting, porting to .NET guarrantee
you completely rewriting. But, if you eventually have make your app as an
exe, (and your app sticks with MS Windows platform), I'd suggest to learn
..NET and do the ,NET porting. When you have it done osme time later, more
(and more) Windows computers already have .NET framework installed. Don't
bother to make it VB6 app, unless you can do it in short period of time.

 

[Luiz Cláudio]

Hi Peter,

to run a .Net app, you'll have high software and hardware requirements, and
as you said most of your users don't have new machines, it would not be my
choice at all.

To make Access Runtime available to your users, the package may be very big
to deploy, but they'll have to download it only once. I would not discard
this option at a first time. Many users probably already have MS-Access
running on their machines (they won't need to download Runtime), and the
others will have to do it only once. The main problem I see here is that
Access Runtime installation and maintance can be tricky and difficult to a
user, so you would need to be ready to provide support to each one of them.
Read this page: http://www.granite.ab.ca/access/runtime.htm
If you are sure you can deal with these problems, distributing Runtime can
be a solution for you.

Other viable solution is to rewrite your app in classic VB (VB6). Even
though Microsoft wants to kill it and throw it in a deep lake, I consider it
a very good tool, and you'll probably be able to use much of the code you
already have running. Anyway, a 40 form/report app will be a hard work to
do.

If I were in your situation and could not deal with Access Runtime problems,
VB6 would be my choice.

Luiz Cláudio C. V. Rocha
São Paulo - Brazil

 

[Bogdan Zamfir]

Hi,

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

No. Access have a different object model thank VB 6 and VB.NET. So all forms
and reports must be ported to the platform of your choice.
However, if you have generic VBA code in your form's modules (so code whuch
doesn't works tightly coupled with the Access interface elements), you might
be able to use it in VB6.

If I am going to all this trouble, would it be better to
move to VB.Net? Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework. If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

VB.Net language is different than VB6, however they are very close, and
you'll be able to learn in quickly. The language is much more powerful,
because it offers some real OOP features (like inheritance) which wasn't
available in VB6 and Access.
VB.NET required NET Framework. It is shipped by already installed with
latest OS from MS (like XP, Server2003), and can be installed on other older
OS (starting with Win98 SE). The NET runtime is about 23 MB, which can be
downloaded without problem if the user have a download manager with resume
support.
However, on slower systems, NET might run slowly than VB6 (which performs
very well even on slower Win95 PC's)

If you make the transition to NET, the application needs fully rewrite, and
in this case it worth an analyze first, to reshape it to take fully
advantages of NET platform and VB.NET language.

If you have the time and resources, a better approach would be to write a
transition version in VB6, to have it available for one or two years at
most, and in this time, to make a full rewrite of the application on NET
platform. Re-writing to VB6 can be done quite fast (if you know VB6 well and
have also some help, it can be done in 1-2 months).

If you have any more questions, or need some help with this project, you can
contact me directly.

Regards,
Bogdan Zamfir
__________________________

Independent consultant

 

[Paul Overway]

The Access XP Min runtime is 42MB...considerably less than 70MB. So, that
may be an option, if end-users already have IE installed, whish is likely.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Answers inline:

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

You will have to port these to VB forms and reports. Access uses an entirely
different object model.

If I am going to all this trouble, would it be better to
move to VB.Net?

Probably - I see no indication that VB.Net is going away. If I had to do
something similar I would take the time to learn VB.Net.

Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework.

Since I have not done much with VB.Net I can't fully answer this question
except to say that when you move to VB.Net you will be giving up the
datacentric convenience of using Access forms and reports. I would assume
that a well written application should perform well in VB.Net but I don't
have the experience to confirm this.

If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

You will have to send the .net framework. The 1.1 framework is about 70MB. I
think the Access XP runtime version is approximately 120 Meg.

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

I have an application written in Access 2000 that I
distribute to a number of organisations who use it on a
variety of platforms, ranging from a P75 running Windows
95 to modern XP machines. It has about 40 forms and
reports and 25K lines of VBA.

I would like to distribute it over the Internet, but I
have to send Access Runtime with the application. This
makes the distributable much too big to download over an
ordinary modem, which is all most of my customers have.
So I am thinking of reworking it in pure VB6, using an
Access (Jet) database connected through ADO.

I have two questions that I wonder if anybody can help me
with.


If I am going to all this trouble, would it be better to
move to VB.Net? Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework. If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

Any comments and suggestions would be much appreciated,
as would any pointers to useful articles or books.

 

[Sandra Daigle]

Interesting - I'll have to go back and check my source for that
information - thanks for the correction.

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

The Access XP Min runtime is 42MB...considerably less than 70MB. So, that
may be an option, if end-users already have IE installed, whish is likely.

Answers inline:

Will I still be able to use Access forms and reports
without Access Runtime? Or will I have to port all of
these to VB forms and Data Reports?

You will have to port these to VB forms and reports. Access uses an
entirely different object model.

If I am going to all this trouble, would it be better to
move to VB.Net?

Probably - I see no indication that VB.Net is going away. If I had to do
something similar I would take the time to learn VB.Net.

Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework.

Since I have not done much with VB.Net I can't fully answer this
question except to say that when you move to VB.Net you will be giving
up the datacentric convenience of using Access forms and reports. I
would assume that a well written application should perform well in
VB.Net but I don't have the experience to confirm this.

If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

You will have to send the .net framework. The 1.1 framework is about
70MB. I think the Access XP runtime version is approximately 120 Meg.

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

I have an application written in Access 2000 that I
distribute to a number of organisations who use it on a
variety of platforms, ranging from a P75 running Windows
95 to modern XP machines. It has about 40 forms and
reports and 25K lines of VBA.

I would like to distribute it over the Internet, but I
have to send Access Runtime with the application. This
makes the distributable much too big to download over an
ordinary modem, which is all most of my customers have.
So I am thinking of reworking it in pure VB6, using an
Access (Jet) database connected through ADO.

I have two questions that I wonder if anybody can help me
with.


If I am going to all this trouble, would it be better to
move to VB.Net? Apart from the worry of learning a new
language, are there any other disadvantages of VB.Net? I
am worried in particular about speed of execution on
slower machines and clients that have not got the .Net
Framework. If I have to send .Net Framework as well as
my application it will negate much of the advantage I
hope to gain.

Any comments and suggestions would be much appreciated,
as would any pointers to useful articles or books.