The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

MS Access 2000 and VB6

Hi Guys

I have made the leap from MS Access 2000 to VB6 and I am trying to rewrite my existing Access 2000 programs in VB6 frontend with Access 2000 backend.

All of the new programs will still use an Access 2000 backend to store and retrieve data, however there is a nagging doubt that I am learning VB6...a programming language that is currently being superceded by VB.NET. So my questions are:

1. Should I Go straight to learning VB.NET?
2. Will VB.NET frontend hook up to Access 2000 Backend?
3. If they don't do they hook up with any later flavors of Access?

Thanks
Jeffrey Lewis Send private email
Friday, November 11, 2005
 
 
1. Given the choice between the two, go straight to VB.Net. Unless you are building a shinkwrap product, then you have to consider that not all users have or will download/install .net runtime.
2. Yep. ADO.Net (OleDBDataProvider) hooks up with Access 2000 database easily.
Wills
Friday, November 11, 2005
 
 
Hi Wills

Thanks for the quick reply. I should have mentioned that 2 of these are shrink wrapped products that are installed with an Installshield routine on the endusers machine.

regards Jeff
Jeffrey Lewis Send private email
Friday, November 11, 2005
 
 
I think you need to consider the goals here.

Why are you considering VB6 over ms-access now? We need to ask that question first, as those answer might shed light on jumping to .net

Without question, VB6 is rather better from a distribution point of view then is ms-access.

However, distribution of a access runtime vs vb.net runtime does even things somewhat (but, longer term future belong to .net..and eventually every machine will have the .net clr).

Also, the a2003 runtime is a good deal better then is the a2000 runtime (at least I think so, and with themed controls your applications screens look quite modern). Here some screen shots of what I mean (they are all ms-access, and not how the button take on the windows xp theme).

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

and

http://www.members.shaw.ca/AlbertKallal/Atheme/index.htm

I mean, if the choice is simply VB6 vs VB.net, then likely the .net is the way to go here. However, it seems you “might” be considering VB6 due to distribution issues, and that is no easy answer.


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Friday, November 11, 2005
 
 
Thanks Albert

At the moment I have a shrink wrapped product that goes to endusers with the Access 2000 cutdown runtime. This ends up at 45 megabytes. Which is an 80 minute download for someone without broadband.

A VB6 frontend would cut this down to 4 - 8 megabytes. This would seem the way to go for any shrink wrapped program with wide distribution.

However, I still get the feeling I am being left behind by staying with VB6 and would like to change to VB.NET..but that large runtime that has to be distibuted with application, is a sticking point for me.

So for now I will stick with VB6 and hope that Microsoft address this problem in the future, or IMHO they will lose this market.

Or am I mistaken??

Regards Jeff
Jeffrey Lewis Send private email
Friday, November 11, 2005
 
 
Hi Jeffrey,

Other factors which will influence your decision may include:

Who is your target market? Corporates? Consumers? SMEs (Small/Med Enterprise)? Are they likely to have the .Net framework now or in the near future. Most corporates I deal with have or are in the process or rolling out .Net, SME often lack the IT infrastructure or company wide software roll-outs.

Many home consumers don’t know what .Net is. My mother had enough difficulties installing her firewall – a one hour .Net installation is a major no-no for the home market. (Eventually we’ll all have it pre-installed)

How is your software distributed to your customers. Are they consumers having to download it? Do they use broadband or (heaven forbid) 56k modem? Do you deliver on CD and customise the installation and set-up for the client?

And, as Albert alluded, what is the impetus for the leap? The answer to this may aid your decision.

All the best
Marcus from Melbourne
Friday, November 11, 2005
 
 
Hi Marcus from Melbourne

Thanks for the info. As my products are shrink wrapped home user programs, I will convert my existing Access 2000 programs to VB6 and leave VB.Net alone for a while.

The change to VB6 achieves a more stable front end and a smaller download. So there is some benefit here.

The change to VB.NET is a lot to learn and because I'll need to distribute with the it runtime, it defeats the object of trying to do without the Access 2000 runtime.

Regards Jeff
Jeffrey Lewis Send private email
Friday, November 11, 2005
 
 
As for the .Net distro... make it two parts.

Part 1:  Just the link to the MS site to install the .Net framework.

Part 2:  Your app (minus the framework). 

This way, anyone who already has the framework (which is getting to be pretty much anyone on XP with automatic updates) just has to download the 8MB app.  Anyone who doesn't has to go download the framework once.

As to VB6 vs .Net.  Assuming you go VB6 now... If you pay attention to future "problem areas" now, when you do switch to .Net, you will have less hassles than if you ignore all the potential "gotchas" and just go VB6.
Eric D. Burdo Send private email
Friday, November 11, 2005
 
 
These guys, http://www.fmsinc.com/products/ , used to sell a utility to convert various versions of Access to VB. I didn't see it with a quick glance at their site this morning. It was reasonable for getting a quick jump on moving code to VB6, but if you used multi-column drop downs, you'd need to purchase some other activeX controls. I personally wasn't thrilled with it, and when I needed to plan for migrating an app with a few thousand tables, and few hundred forms, and tens of thousands of lines of code, it was a start.
Peter
Friday, November 11, 2005
 
 
VB6 is dead. Distribution issues with .Net are going away.
DJ
Friday, November 11, 2005
 
 
VB Classic is hardly dead.  It is just moving to the more specialised instances. 

It all depends on your target environment.  If you can get away with the .NET runtime, then I would migrate.  If your clients are still stuck in a Win9x platform, then you might want to stay with VB Classic.

There are still many perfectly good places for VB Classic.  Just as there are perfectly good places for .Net, Perl, Java, Delphi, etc.  You just need to weigh the pros and cons first.
Eric D. Burdo Send private email
Friday, November 11, 2005
 
 
i would follow a 2 step approach: a first refactoring & release in access+vb6  -  this allows you to improve your product in the immediate term keeping your customers happy.

And then i would spend my time for the 2nd step: you should go beyond the oldish architectures and build a .net client based on xml files instead of access2000 ......  with ado.net objects you can use xml files just as they were a "classic" db data repository  - xml files instead of tables ;  local file system instead of a database connection... I think this is the best way of doing a stand-alone client with a data repository hidden behind a user interface.

Think of what they're doing with Vista: the basic idea is similar - treat the file system like a db.. we access our files (data in tables) through "vistas" (views, queries)
Johncharles Send private email
Friday, November 11, 2005
 
 
You can access xml data in ado.net but I wouldn't recommend using xml as database at this stage. It's slow for any data of decent size (yep slower than access).
If your reason for upgrading is mainly to do away with runtime then yeah go with vb 6 (unless if you are prepared to learn and jump to Delphi).
Wills
Saturday, November 12, 2005
 
 
The a2003 runtime is 33 megs in size So, you might chop 10 megs out by moving to a2003 runtime.

However,  I would take a long hard look here at how much you gain by reducing the download size.  For me, if my clients can afford my software, they have high speed. I have not had ONE client yet who has not had high speed.

I not saying this is not a problem, but you have  evaluate your customers. Can customers who can’t afford high speed afford your software?

>used to sell a utility to convert various versions of Access to VB.

FMS makes first rate products, but unfortunately conversion of ms-access to VB6 can only “help” you with the layout. There is big number of reason for this, but a few are:

No continues forms in VB6. I briefly talk about how incredible this feature is here:

http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm

Not only don’t you have no multi column combo boxes, but no multi-column listboxs either. And, worse, you don’t have a sub-form.  All of those forms in the above link use sub-forms to model the “one to many” that a database has.

You also don’t have a forms object model that is bound. This means you don’t get 3 events to deleting records (on delete, Before Delete confirm, After Delete confirm).  And, same goes for a zillion other events that you got in msa-ccess forms (before insert, after insert, before update, after update , on dirty.... this  list is so large, and VB6 is so lacking in this department).

Each one of these events has a special use, and if you know ms-access well, then you know exactly when to use what event for what (this means ms-access has a MUCH steeper learning curve then does VB6 forms). Again, we have two form events when you launch a form (on-open, and on-load). The on-open event allows you to test things, and actually prevent (cancel) the form from loading (in VB6, this is royal pain).

You also don’t have the report writer, and again have to convert reprots also.

However, a conversion tool can be a good start, as it least lays out the forms, and at least creates some of the data connection controls for you. So, it is certainly can be a time saver…but you can’t really get a conversion utility without duplication the of ms-access object model.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, November 13, 2005
 
 
Albert,

Having used VB6 (actually VB-DOS through VB6) quite a bit, I have to disagree. VBA, the underlying VB engine in MS_Access is a subset of the VB6 engine. It may be a chicken-egg thing at this point I haven't looked into Access/VBA for eons. Every property and event available in VBA (with possible rare exception - I don't recall a IsDirty) exists in VB6. In fact I'd comfortably hazard to guess that VB6 may in fact offer more ... much more, possibly.

The forms object model is not bound, correct, but the data control that connects to the database is feature rich in properties and events - again, quite possibly more so than the VBA bound forms. The data aware controls that connect to (show the data from) or navigate through the data (from the data control) further enhance the properties and events of the underlying connection. The forms do in fact have events that would allow you to validate (anything) and abort if necessary.

There is also a report engine in VB6 although I've never used it. The "Microsoft Data Report Designer" apparently which may also be what you find in VBA. Crystal Reports had been bundled with VB up to v6 but between the two of them (MS and CR) they buggered it up for the VB6 release.

Having said all that having seen what you (and some others that I work with) have done using VBA, I'm impressed. Having gone the other route, I'd doubt if I'd go there but like I've said some of the results are impressive.

VB6 is a very powerful tool and it works natively with JET and Access. As to the OP, an app created with VB6 will be around for a long time. Having said that, you might want to dive in and go with the latest and greatest, specifically if you're just learning. Starting out with VB6 will not reduce what you will have to learn at some point ... it may even lead you in the wrong direction.
PNII Send private email
Sunday, November 13, 2005
 
 
Jeffrey,

You currently distribute a shrink wrapped product that goes to end users with the Access 2000 cut down runtime which weighs in at a (depending on perspective) hefty 45 megabytes.

The .Net runtime/distribution is pretty much a no brainier compared to this. It's (version 1.1) only half this size. You don't have to distribute it, your users just need to know it's required. They get it at their convenience. Go with .Net IMO.
PNII Send private email
Sunday, November 13, 2005
 
 
Jeffrey,

You may find this post from the main forum an interesting read:
http://discuss.joelonsoftware.com/default.asp?joel.3.247658.25
PNII Send private email
Sunday, November 13, 2005
 
 
As the original poster of this thread, I can only say that you guys are wonderful with all the help you have given me.

As I see it, there should have been VB7 and VB8, but that is never going to happen. So to spend time becoming an expert on VB6 is probably not the way to go.

Having said that, small downloads do look attractive, but as someone says in the thread, VB.Net has been with us 4 years and is not going to go away.

So my strategy will be to rebuild my existing applications in VB.Net frontend and distribute with an Access 2003 backend.

Along with the usual dependencies, I intend to distribute the Dot.Net framework that will install on an enduser's machine if it does not already exist there. Hopefully this is feasible and anyway, it is smaller than the Access 2000 runtime.

If anyone can see any big flaws in my thinking, I would be grateful if you could point them out.

Regards to All
Jeffrey Lewis Send private email
Tuesday, November 15, 2005
 
 
VB6 is DEAD!!! The only people using this software today are going to be the hard heads that won't switch over because of their existing investments in it....so that is the only reason that VB6 will be around for a while....but I can't think of a single reason why one should develop any NEW solutions with this software.....

VB.Net is going to gain more momentum as time moves forward.....and as soon as the trend of incorporating an ENTERTAINMENT element to software becomes a reality (you haven't seen it yet but you will)......no one will even remember what VB6 was.....
Brice Richard Send private email
Tuesday, November 15, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz