Note that this question is not meant to start an argument, I am genuinely curious:

Back in the 90s I used to work for a large CPU maker and we were building some debuggers. All our core logic was in C++, but the GUI was made in VB6. We couldn't figure out MFC and it was too much a hassle. We glued together VB6 and C++ using COM which we created via ATL.

Fast forward to 2009, having been mostly in the Java world I am looking at job boards and seeing more VB6 jobs than I expected. I genuinely thought that VB6 was extinct, especially since VB.NET supposedly solved a lot of the problems with the VB6 which at the time felt a lot like a scripting language than a true OOP language.

So what happened? Why is new code still written in it? Isn't there a better way to glue C++ and VB.NET?

Note that I haven't used VB.NET, I just understand that it is a much more "stricter" language than VB6 was. Even with Option Explicit or whatever it was.


the last (small) company i worked for liked to stick with familiar technologies, as the development team was small and consisted of one member who was constant - all new things are being built with .NET, however. i'd be surprised if those weren't maintenance programming jobs, intended for work with legacy systems rather than new applications

+60  A: 

The key to the ongoing popularity of VB6 is that it's really easy to code, creates useful applications quickly and users don't care what language the app is written. Of course there are now better languages, but better for who - the users, the millions of people who know VB6 well enough to create apps, or developers who know the best way of doing things?

The learning curve to get to .Net or Java is just too high for many people. To look at another example, you couldn't get much simpler than straight HTML, yet that created the biggest revolution in computer usage. As languages are designed by IT gurus they tend be designed for IT gurus, shame that all the users really want is simplicity.

Well written answer! Where's the +2 button?
Wayne Koorts
Not true for me and my colleagues. Love learning new stuff. BUT lots of "legacy code" (a.k.a. actual working profitable apps). VERY VERY VERY cross at Microsoft failure to provide easy upgrade route. Especially since 3rd parties have done better e.g.
I've worked with users and introduced them to VB/VBA normally to support utils that they can fix/extend themselves. I completely agree about the upgrade path - what should these people do - carry on with VB.
MORE: Microsoft UK surveyed VB6 developers in January 09, and found that at least 45% are using .NET as well as VB6. Many of us love learning and are using VB.NET for new development, but we have actual working applications ("legacy code") that still need maintenance.
Can you link us to the survey, or anything else that shows what MS are thinking of with respect VB
Here's the link (sorry for delay, I only just looked back here). You might also be interested in the Windows 7 support statement for the Visual Basic runtime
Cheers Mark, interesting to see the reality of VB6 usage, it surprised me and I expected there to be a lot of it still out there.
Paul Yuknewicz, Program Manager in charge of VB6 at Microsoft, said in Sept 09 that there were still several million VB6 developers.
Totally agree. procedural and structured programming just needs logic. You don't mess with objects, classes, statics, protected, overrride, virtual, sealed and all that stuff that comes with OO programming.

As much as I hate VB (and VB.NET), it does do some things well enough to warrant its existence. It is good for building GUIs, and maybe some other unknown things. I would guess that compatibility is a big reason for people to keep using VB6. Also, I think the people that tend to use VB (especially VB6) aren't always interested in the latest trends, they just want to get the job done in a way they know how.

Andy White
Why do you hate VB? It kept many of us employed for many years
It's just so ugly :) "If Not EmailAddresses Is Nothing Then"... gross
Andy White
@Andy White - You can't be serious. There is no difference between that and comparing to null in C# or Java. [if (!(EmailAddresses == null))] isn't any better. Any programmer can write not logic in any language and make things confusing.
I think you are fighting a losing battle here :) Writing or reading VB code feels like trying to use a really bad speech recognition program.
Andy White
VB is ugly (IMO), it's far too verbose, and can be very hard to read. This doesnt however mean it's not a useful language for small apps. and VBA is vary handy for automating Office.
Neil Aitken
Microsoft UK surveyed VB6 developers in January 09, and found that at least 45% are using .NET as well as VB6. Many of us love learning and are using VB.NET for new development, but we have actual working applications ("legacy code") that still need maintenance
@Andy: You've got to be kidding, right? I'll concede that VB has its flaws, but comparing it to a bad speech recognition program is really unfair. I suspect the reason you don't like it is that you prefer the more terse C syntax. Brevity is good, but you have got to admit verbose languages are generally easier to read. Consider this, which one do you think an person with no prior knowledge of the syntax or keywords is going to be able to more easily follow?
@Cris: I think it was a mistake to ask why he hates VB. It created a discussion about what language are better (which has nothing to do with the original question), and this is just a matter of taste; someone likes verbose languages better, and others hate it. That's just a fact. I actually like both. C# and VB both have strengths in different areas. The rest of his answer (after the hate-statement) was actually useful as answer to the original question.
Hey Mr Terse, why aren't you using Haskell? All those curly braces and semi-colons in C, pfweh!

Part of it may be that VB6 was so successful within larger organizations for doing enterprisey apps; VB6 is the new COBOL. A lot of organizations don't have the time or inclination to "port" VB6 to VB.NET or C#, it's just not a priority for the business. For a lot of systems, VB6 is still "good enough".

Patrick Cuff
+31  A: 

My company flat out has too much code in vb6 to port it out. Most likely this will happen in the relatively near future (to take advantage of 64 bit), but its (mostly) stable and mature. A rewrite will probably take 10 developers 3 years working full time. If you have something that is mature, it doesn't make good economic sense to port it unless there is a good reason.

We have spent about 3 years converting our main VB6 codebase into VB.NET. I started alone with the 2 others joining later. We are not completely finished with a releasable version, but are now in a test/fix period with much work remaining on the **fix** part... The biggest issues are in GUI, and most related to the MS FlexGrid control. We have tweaked the interop version of FlexGrid to get it right, but later we plan to use some .Net grid controls instead.
So you'll be finished just in time to start porting to the next environment :)
+2  A: 

Another reason, in addition to the reasons above, is that it's extremely easy to deploy a VB6 application. There's no 250 MB redistributable to pull down (with all due respect to

So where is the richtx32.ocx redistributable? Needing to put stuff in c:\windows\system32 and having to register it is not what I call *extremely easy*.
Wim Coenen
It was hard enough getting all that done back in 1998, how do you do it now? I don't even know where to find it.
If you restrict yourself to the VB6 core runtime, it's preinstalled on modern versions of Windows. And you can use registry-free COM (XCOPY deployment) for things like richtx32.ocx. But "extremely easy to deploy" is going a bit too far - I don't agree with this answer.
It's been my experience that nobody could run my VB6 applications without pulling down the VB6 redistributable, but my VB.NET apps worked out of the box because .NET Framework was already installed.
Hmm, that's a bit weird Scott. The VB6 runtime is standard on all versions of Windows since Windows 98. .NET framework was released in February 2002, so wasn't built into XP.
There are many things in the VB6 that are useful and not available without a additional installation, including registering COM and/or ActiveX stuff. Most Windows users now have some version of .NET Framework installed, and if they have set up automatic updates using Windows update, they get the latest versions automatically. The .NET framework includes all you really need in an application - and more. If you need to use 3rd party stuff, you can include it in your app bin folder with no need for registration of any kind.
You referred to hanselman-smallestdotnet, which tells you that the Framework is never larger than 60 MB for 3.5 SP1 (worst case scenario if you have NO versions of .NET installed before)
I remember when the VB runtime was a hassle because it was 5 megs -- too big to fit on a floppy.
Michael Itzoe
+3  A: 

VB6 is still used simply because there is no simpler way of creating COM objects, and there are LOTS of systems that are COM based - for example the whole Office suite. .NET did not fill the COM void, and I think they should still offer VB6 inside the current Visual Studio line up.

Otávio Décio
It is very easy to make a .NET dll COM visible (just a simple setting in the project), and quite easy to expose members with full COM interface (a setting on the methods/properties to expose).

A lot of companies do not find it necessary to immediately rewrite their software to a newer technology unless it is mission critical or will save them money...

They find it cheaper to maintain rather than rebuild.

This is why there are still a need a COBOL programmers.

Michael Kniskern
+2  A: 

Because it is RIDICULOUSLY easy for a non-developer to understand and use. In the corporate world, many non-programmers start programming with VBA (e.g. in Excel) ... transitioning to VB6 is a natural progression.

+2  A: 

Visual Basic up through VB6 was the way to create small simple applications. It offered instant gratification (for example GUIs with no coding whatsover) and still had a moderate amount of power once you needed it. It did have a runtime library, but it was nowhere near the size of .NET's current one... tiny apps still only required a few MB of RAM.

I remember back with .NET 1.0 when Microsoft decided to can VB6 in favor of VB.NET, there were tons of people who predicted that people wouldn't want to move languages, and would stay with VB.NET. Looks like they were right. MS also provided an upgrade "Wizard", which was supposed to simplify the task of upgrading apps from legacy VB to VB.NET. If I remember correctly, it didn't really work very well.

IMO VB.NET is no longer "Basic" anymore, but people still want a simple no-frills way to create applications. VB6 is probably the only way for the "layman" to get started programming.

You remember correctly about the upgrade wizard. It's rubbish. See my answer.
+4  A: 

Two reasons: VBA and legacy code.

VBA is still COM based. And I know how to write stuff that works with that in VB6. I don't even know how you'd use .net code from VBA. I've never tried or researched it. Honestly I'd just like to keep the two separate anyway. Secondly there are tons of legacy applications out there in business. And they need maintenance. And nobody wants to rewrite them for technologies sake. They just want to get their work done.

Also remember that VBA is not office only. There are other apps that use it. I work with one extensively and it has a very large deployed base. Not every client uses the vba functionality but several do. All my web based work is using But the desktop work is still VB6 and VBA based. We are even producing new VB6 apps designed to work with the application. But 90% of the work is maintenance, fixing long term bugs or adjusting functionality to support new requirements.

Will Rickards
+1 for mentioning legacy code. Considering that even COBOL programmers can find decent work today.
+1 for mentioning the upgrade wizard. If you've ever tried it on some legacy project you might find yourself pulling out your hair
Legacy code is at times annoying but at the end of the day, some of those ancient machines will still be creaking on 20 years from now. Always good to know COBOL for maintanence.
Christian Witts
"Legacy code" = actual existing working program that is of some value. Do not underestimate its value compared to something that only exists in the head of a keen young coder who's desperate to rewrite. (I have been that person.)
It is very easy to expose a .NET project as a COM. It is even easier to reference a COM dll in a .NET project. It is event possible to generate a COM interface (using a build in tool in the .NET SDK) for a .NET dll that is not originally exposed to COM.
+9  A: 

VB6? I would happily use this if there was a demand: :-)

The Clipper Compiler, Summer '87
Copyright (c) Nantucket Corp 1985-1987.  All Rights Reserved.
Microsoft C Runtime Library Routines,
Copyright (c) Microsoft Corp 1984-1987.  All Rights Reserved.

                Richard McConnell & Brian Russell, Sr. VP

                Kevin Shepherd      Dennis Dias
                Rick Spence         David Dodson
                Jon P. Rognerud     Fred Ho

                -l   (no <l>ine numbers)
                -m   (compile one <m>odule only)
                -o   (<o>bject file drive and/or path)
                -p   (<p>ause for disk change)
                -q   (<q>uiet)
                -s   (<s>yntax check only)
                -v   (<v>ariables are assumed M->)

                @list.clp (list of files to compile)

        A>clipper a:main.prg -p -ob:
        C>clipper @list.clp -l -q

Or this (OMG, I can't believe the executable still runs 22 something years later):

│                    dBASE III PLUS  Version 1.0 IBM/MSDOS                     │
│     Copyright (c) Ashton-Tate 1984, 1985, 1986. Alle Rechte vorbehalten.     │
│              dBASE, dBASE III, dBASE III PLUS, und Ashton-Tate               │
│                     sind Warenzeichen von Ashton-Tate                        │
│                                                                              │
│       Sie sind berechtigt die dBASE III PLUS  Software sowie das gedruckte   │
│       Begleitmaterial  zu  den  Bedingungen  des  Endkundenlizenzvertrages   │
│       zu nutzen.  Der wesentliche  Inhalt  dieses  Lizenzvertrages ist es,   │
│       Ihnen eine  nicht übertragbare,  persönliche Lizenz zur  Nutzung von   │
│       dBASE III PLUS  auf einem  Mikrocomputer oder an einem  Arbeitsplatz   │
│       zu gewähren.  Die geistigen  Eigentumsrechte verbleiben bei  Ashton-   │
│       Tate;  Sie dürfen die  Software und das  Begleitmaterial weder  ver-   │
│       vielfältigen  noch  verändern.  Jede Verletzung des  Lizenzvertrages   │
│       oder Urheber- und Warenzeichenrechte kann rechtlich verfolgt werden.   │

                           Drücken Sie F1 für HILFE.
Befehlszeile    ║<W:>║                       ║                   ║      ║
  Geben Sie einen Befehl (oder ASSIST) ein und drücken die RETURN-Taste (◄─┘)
                     Einen dBASE III PLUS Befehl eingeben.

Why am I posting this? Because VB6 is not the first technology that became obsolete, and because there is something to learn from earlier examples - namely that popular languages are hard to kill. People were still developing DOS-based applications with Clipper well into the 1990s, and many of these applications lived past Y2K. The productivity of this platform was simply amazing. Of course there was a point when IT managers could no longer justify an investment into this obsolete platform, and it disappeared relatively quickly, as there was no migration path. Character-based applications just did not appeal to Windows users, and Visual Foxpro was a marginal product, compared to the popularity of DBase and Clipper.

Oops - a down-vote, probably from a Foxpro developer.
I still have my clipper and dbase II plus disk...unfortunately all on 5 1/4 floppy disks! Haven't seen on of those drives for years...
+1  A: 

My company still has many VB6 apps running in production doing critical tasks server based tasks that would have been better suited for languages such as Java, C or C++. A rewrite would take years just because of the domain knowledge that has gone out the door.

I often wonder why anyone was crazy enough to write applications in VB of all languages. It is mostly because it is easy to learn while Microsoft makes it so easy to drag and drop things.

The glut of old code is probably still around and someone has to maintain it, just like COBOL.

Maybe people were "crazy" enough to write in VB6 because it was a far more productive language than C or C++, and at the time Java was at best cranky? Just a thought!
@MarkJ-There is always a right tool for the job. You are right about the productivity thing, but, we have similar Java apps written around the same time as the VB6 code (~2001). We do a lot of tcp/ip socket work that doesn't need a GUI (see the contradiction?). We still have issues with the VB6 app.
@MarkJ, its not that I mind VB6 its that for me at least, it has produced really crappy code that I have to maintain.
Blame the poor workman not his tools.
+2  A: 

I remember something Simon Peyton Jones said in a talk. (Paraphrasing) Based on number of users, there is a line that once a specific language crosses, there is so much code written in it that it basically cannot die.


It's very easy to write very bad, unmaintainable code in VB6, and harder and harder to find developers who can maintain it.

I fear that the majority of companies still using VB6, Classic ASP, Windows NT 4 or 2000, and other legacy "code" will eventually learn why "it ain't broke" was not a good idea. These are typically the same companies who do not document their code well, or even lose the source code, and continue to take no action because it "ain't broke".

In the meantime, they are slowly losing the knowledge necessary to fix the old code or to port it or rewrite it. They will need to pay more and more money to hire good people to maintain the code, or else pay less for those who can't find work elsewhere and will work wherever they can get paid.

And even in static industries, nothing is static forever. They'll eventually have a customer who wants web services added, or a competitor who has exposed their functionality on a web site, and they'll want the legacy code to compete with more modern requirements. And then they'll find out why the legacy languages were largely replaced by what came later.

I should add that I've seen one very good web-based application written in VB6 with XML, XSLT and JavaScript. The largest problem they had was that some of their modules had become too large. Not a very big problem. But, having seen that application, I know why the exception is not the rule - it took some very smart architects to create a flexible, maintainable and well-documented architecture that this company has been able to build on.

Most VB6 applications I've seen aren't like that.

I also want to add that I have not included COBOL in this list. There's so much intertia for COBOL that I don't expect a lack of COBOL expertise until next century. It still suffers a bit from lack of knowledge, but in the other direction - how many people know what a "copybook" is, or could help someone figure out how to serialize it? How many people have any idea how to call a web service from a COBOL program? Not that it can't be done, but most of the people who know about serialization or web services don't know anything about COBOL, and so couldn't help.

Code that never needs to changed, looked at, or even thought about, is code that really "ain't broke" in my opinion. Write it in Assembler without comments, for all I care.

Any other code needs at least to be changeable, readable, and understandable, not just today, but tomorrow, if you plan to have a tomorrow. Otherwise, you'll find a day when nobody can understand, read, or change the code, and you may some day need to do so.

Note that I suggested that adequate documentation is as good as keeping the code up to date. It may be necessary to include the manuals for VB6 in the documentation package, in order to train developers who have heard of VB6 only from their grandparents, but it should be possible to document the code well enough that only time is wasted when it needs to change.

It could be done, but in many cases, it won't be done.

John Saunders
"It took some very smart architects to create a flexible, maintainable and well-documented architecture". Last I heard, the silver bullet still hasn't been found and this is true of any language?
I meant that if they hadn't created that architecture, all the developers would have been left with is the normal undisciplined VB6 mess. The application would never have shipped v1.0, much less succeeded in the marketplace.
John Saunders

Absolutely, you could say the same for VBA. Most people can Google for macros and stitch together simple scripts to get their jobs done. For most, that's all they really want.

In addition to all the answers here, some companies outsource their development, and as such, impose restrictions on developers. For example, "we are not allowed any software such as .NET or JAVA, so you have to write the app using VBA or VB6". I'm dealing with this right now, I have to cast my mind back, but I'd rather use VBA atm moment than MFC.

And as mentioned, legacy apps. Most of these are large, often poorly refactored, maybe the source was lost or the company who wrote it isn't around, or the developer is deceased, or isn't broken, so why mess with it? We all know what this leads too, but for the most non-developer staff it doesn't really matter to them. They wistfully do their jobs and do not care about how it looks or works, just that it does.

And just because something is dated and stale isn't enough reason for management to give permission to rewrite it.

One last thing, maintainability. VB6 is a heck of a lot cheaper to maintain than MFC. Anyone who knows MFC well and didn't get sucked up in the .NET and JAVA worlds is pushing 40 and is going to cost a lot of money.

+2  A: 
  1. Easy to use
  2. It usually works first time
  3. Plenty of example code.
  4. Allows you to make an application without spending a year to understand a complicated framework of goobly gook.
  5. There are no traps for beginners.
Counterpoint to #5: "DoEvents"
Scott Whitlock
+3  A: 

In addition what Steve said there are several features that VB6 still has a more ease of use (graphics and printing). VB.NET has closed the gap in many ways and while VB6 may be easier to use VB.NET is more capable. The only major usability problem I consider remaining is Printing. However Microsoft has mostly addressed that in the Printer Compatibility Library in VB Power Pack. Since the 2005 release, for a NEW project, I can work pretty much the same way in VB.NET as I can in VB6.

The real pitfall is still backwards compatibility. Microsoft blew their foot away with that. This was made even more egregious when it was found out that that many of the changes were NOT required by the .NET runtime. For example having Integer compile to a Int16 instead of a Int32. As more and more languages (F#, Boo, Python, etc) were released it became evident that that MS's decision not to support backwards compatibility was an arbitrary decision. This caused a loss of trust in Microsoft as a vendor for many VB6 developers.

This is a critical issue because working code is a very valuable asset and is not lightly abandoned.

The need to maintain working code and loss of trust are the two main reasons why VB6 persists to this day. The amount of NEW projects started in VB6 is probably minimal.

RS Conley
+2  A: 

In My Opinion, #1 reason is that Microsoft gave no viable (practical/usable/workable/choose whatever word you want) upgrade path from VB6 to .NET like they did for all other versions prior.

The #2 reason is that it still works for its intended purpose - Rapid Application Development (if you can still find a copy to purchase that is).

So many people (myself included) have stopped at VB6 to preserve years and thousands of lines of code.

**Hundreds** of thousands of lines of code...
+1  A: 

One factor may be that in its heyday so many people used VB5 and VB6 that no other programming language effectively existed. Even assuming 90% defection for numerous reasons since The Great Disgrace that leaves a lot of VB6 programmers yet if you consider sheer numbers.

The architecture of .Net parallels that of Java, for good reasons. Mostly that it's a ripoff. Thus it inherits many of the same handicaps Java has, being a poor choice for desktop development and strongest on the server. However .Net still lacks some key components that the Java ecosystem does have, primarily decent app server support in the form of Java EE (formerly J2EE). Even many Java programmers don't seem to comprehend what the EE platform brings to the table, perhaps because those using it take it for granted. Microsoft hopes to address this with what looks like a BizTalk rewrite (codename Dublin).

So VB6 is left with a huge niche that it only shares with less productive tools (C++) and quirky minority tools (Delphi). For low volume shrink wrapped desktop software VB6 is hard to beat, especially since the advent of registration-free COM in Windows XP and bundling of stable VB6 runtime components as part of the core Windows installation.

Where VB6 is weakest is its Web and server-side stories. The latter is reasonably well addressed via COM+ but still needs refinement. Good VB6 support in IIS was never developed beyond a first attempt (Web Classes, the conceptual precursor to ASP.Net). Another growing problem is multiplatform interoperation. As the world shifts further toward Web Services VB6 lags in terms of tools support, though at least there are functional if limited options.

WPF is doomed to die because it was developed in such a way as to be extremely difficult to use from non-managed environments. So you have a desktop-centric technology that cannot easily be used from the prime desktop development tools. Its only real hope of success would be a follow-on to VB6 that offered full IDE designer support as well as runtime support in the form of wrapper objects for the underlying technology.

WCF faces the same fate but Microsoft has seen the light in a small way, providing at least C/C++ support at this point via the new WWSAPI.

There is no question that VB6 needs a facelift desperately. But even so there just isn't a good alternative available. Fortunately there is still a strong community, and as time goes on workarounds are developed to help VB6 programmers cope with changes.

And yes, lots of new VB6 software projects are undertaken daily. It is entirely a myth that VB6 is only being used to maintain old applications.

"that no other programming language effectively existed" ... I stopped reading at that point.
@Unsliced: I agree that this was a "read stopper", but **some** of the other paragraphs are actually worth reading (not all)...
+16  A: 

VB6 is still being used because Microsoft made it difficult to migrate VB6 code to VB.NET. Which part of that is hard to understand?

Microsoft's own advice (screencast) is that VB6 applications should only be moved to .NET if major changes are planned. It requires significant effort to migrate them with the built-in VB.NET upgrade wizard - that's according to the original developer of the wizard.

Personally I find the suggestion that VB6 developers don't like learning very irritating. Microsoft UK surveyed VB6 developers in January 09, and found that at least 45% are using .NET as well as VB6. Many of us love learning and are using VB.NET for new development, but we have actual working applications ("legacy code") that still need maintenance.

Microsoft's decision to abandon VB6 applications was controversial and alienated many loyal VB6 developers. It was noticeable that Visual C++ code was treated with more respect - there was no suggestion that Visual C++ would be retired in favour of C#. As RS Conley has said in his answer, it has become plainer and plainer that many of the changes that broke VB6 code were not required. Also, Artinsoft and CodeArchitects are now offering proprietary tools that apparently migrate VB6 applications to VB.NET with very little manual effort. Microsoft UK are recommending these tools as better than the built-in wizard. This shows that Microsoft could have provided far more help. Personally I believe they should buy one or both of these companies and make the tools available free. I may start my own petition!

I been dealing with conversion between VB6 to .NET since the initial release in 2002. My feeling for a lot of the process is "Why the hell am I doing this? This is MS's Job.". For example I reverse engineered the VB6 graphics engine out of the Printer Library found in the Power Pack.
RS Conley
Aside from the technical reasons for using VB6, the fact that MS supported it's dialect of BASIC for a number of years and that it was the single most popular programming language on the planet made VB6 seem like a safe bet.
RS Conley
Totally agree. Back then, I would have laughed if you'd suggested there would be no upgrade path.
We're not laughing now...
No we aren't!
+4  A: 

It is still used because many, many companies have a lot of code written in VB6, and Microsoft didn't leave developers with an easy way to upgrade this code to .NET. Large applications usually have to be rewritten in .NET to work the exactly the way they did in VB6, and most businesses don't have the time or the money to make this happen, so they would just rather maintain their VB6 code so long as it gets the job done.

+1  A: 

One of the main reasons is legacy apps written in VB6 some of which would cost too much to port to a newer language. The previous company i worked for had two of their biggest products written in VB6.

They chose VB6 at the time (and still use it along side .NET for new products) was its speed ease of use, and the ease in which a new dev. can pick up the language.

Personally I always recommend people who are interested in programing to start with C# and only if they really find it hard to fall back to VB.NET.

+1  A: 

In addition to some of the great answers already posted, let me throw one more in.

For the same reason that people use a lot of legacy software.

If it ain't broke....

+1  A: 

I guess the two main reasons are the same as for why people still program in COBOL: tons of old code that ain't broken so it's still in use daily, and because people like it and it does what they want. Any programming language is a tool; if you like using a hammer to knock in nails, why should you switch to using a screwdriver to do that? Hammers work well for knocking in nails. Sure, using a screwdriver instead might be sexy, and maybe all the cool kids use screwdrivers these days to knock in nails, but if you don't really really need to, why should you? Use the best tool for the job at hand. For many people, the tool is VB6.

+2  A: 

Our business software is written using VB6, and this is painfully obvious. Usually, it is the choice of a developer (company) to stay with VB6, for If they decided to change to VB8 (or even 2010) and rewrite everything, restructure their database schemas, redesign all their interfaces, and offer a much needed deployment method, the cost, both in time and culture shock, would be so great, that it might just put the developer out of business. It is far more profitable to stick with the old, leave it full of quirks, non-intuitive interface conventions, and a planned and billable need for user support plans. For if, the software was rewritten and deployed in a manner consistent with something like MS Office or Quicken or other mass distributed and constantly upgraded software, their customer base would have to grow by ten-fold to generate enough revenue to make a profit. Developers of niche category software depend on semi-monopolistic business conditions to ensure their survival and maximum profitability. There simply is no incentive nor outer force that compels them to modernize their product. 

I don't see how changing from VB6 to VB.NET would require you to change your database schema. In fact, if your database interactivity was implementing using stored procedures, then you wouldn't need to touch anything on the DB side altogether.
Babak Naffas
@Babak Naffas: Unfortunately a lot of legacy VB6 apps are horribly tied to the schema, and remember there were few if any ORM frameworks available for VB6. With things like NHibernate, we take it for granted that we can normalize a database and only update the mapping, so we don't break the app, but in the VB6 world, changing the database usually makes the house of cards fall down.
Scott Whitlock