Converting Visual Basic 6.0 to modern code

[techgnome]

1) Don't convert for the sake of converting. IF it works, leave it alone.
2) Having said that, if you want to make changes, your best bet would be VB.NET (and you can get the Express edition for free from MS)
3) DO NOT CONVERT. Let me repeat that DO NOT CONVERT. Re-write the application. You'll still be able to recycle some of the code, but for what it's worth, do not use the converter to upgrade your VB6 app to .NET. It does a hack job at that, and in some cases, doesn't event do a convert, but just wraps things up.
4) You'll want to learn how to use ADO.NET ... which is a different paradigm from previous database models. There's an FAQ/Tutorial in our Database section that gives a pretty good overview.

-tg

[Paul-NYS]

Hi
We have 2 problems with VB 6.0/Access in its current state:

1. We have about 40 agencies using an individual copy of the application/code and they each FTP us some data out of their individual systems which we store in an Oracle database. We want to build one overall system which these agencies can log into over the Internet. So we would like an architecture that can support this.

2. VB 6.0 seems barely supported in Windows 7.0 and I believe Microsoft has stated they will not support it in operating systems beyond Win 7. So it seems we have to migrate.

What is the best way to deal with both of these problems, given the current VB 6.0/Access architecture?

Paul

[Max Peck]

Hi
We have 2 problems with VB 6.0/Access in its current state:

1. We have about 40 agencies using an individual copy of the application/code and they each FTP us some data out of their individual systems which we store in an Oracle database. We want to build one overall system which these agencies can log into over the Internet. So we would like an architecture that can support this.

2. VB 6.0 seems barely supported in Windows 7.0 and I believe Microsoft has stated they will not support it in operating systems beyond Win 7. So it seems we have to migrate.

What is the best way to deal with both of these problems, given the current VB 6.0/Access architecture?

Paul

Hi Paul,

1) If you re-develop your application in .Net (VB or C#) you will find that you can set up a SQL Server (probably Oracle, too) DB on a web server and have all 40 of your clients use it. I just reached the point with an app I'm working with where the app can access a local SQL database and the one on my web provider - exactly as if they lived on the same machine. I was, frankly, surprised at how good the performance of ADO.Net was in talking across the web. It takes some time to figure out how everything works but it's worth it. I probably could have pulled that end of it off with VB6 talking to SQL through ADO but I don't know if the linkages would have been as reliable. .Net was built to do this.

2) Yeah ... I began to discover this. VB6 was running in my Win7 environment "OK" but the IDE is beginning to show it's age and seems less stable, particularly under Aero. After using VS2008 for awhile VB6 really does seem dated. I still love it (VB6) but I finally realized that using 10-year-old technology isn't going to cut it any longer.

Like any project, do your up-front design first of course. There's a learning curve to get through - a steep one. You'll be on this particular curve for a good while (as I am) but you'll be pretty amazed at the capability that's "built in" to .Net as compared with stuff you had to do manually in VB6. Try not to be intimidated by the feature set; you can still keep things relatively simple once you pick the features you'll use. For example, I developed a simple library (DLL) that abstracts ADO.Net for me so I can get at SQL very simply.

Just be patient with yourself as you make the switch. It'll take time but the technology has matured nicely. It'll work.

-Max

[Max Peck]

1) Don't convert for the sake of converting. IF it works, leave it alone.
2) Having said that, if you want to make changes, your best bet would be VB.NET (and you can get the Express edition for free from MS)
3) DO NOT CONVERT. Let me repeat that DO NOT CONVERT. Re-write the application. You'll still be able to recycle some of the code, but for what it's worth, do not use the converter to upgrade your VB6 app to .NET. It does a hack job at that, and in some cases, doesn't event do a convert, but just wraps things up.
4) You'll want to learn how to use ADO.NET ... which is a different paradigm from previous database models. There's an FAQ/Tutorial in our Database section that gives a pretty good overview.

-tg

Concur. For the longest time I wanted to stick with VB6/Access. Easy to set up, code and deploy. I still like VB6 but it's becoming seriously dated. VB.Net (or C# in my case) and SQL Server (Express or otherwise) is now the best platform. I'd also like to re-emphasize point 3 - DO NOT CONVERT.

As a fairly new .Net convert myself I can't stress this point strongly enough. To write code effectively in .Net you have to think differently. The fully object-oriented methodology is different (in many ways a LOT better). Even this old dog finally realized that there are things I am now pulling off with C# that I would never have been able to do without great difficulty with straight VB6. Rewrite your application. Take the time to learn the new techniques associated with it, too ... don't just write VB6 in .Net. You'll miss out on coding ability that simply did not exist 10 years ago.

It takes a long time for me to adopt new methodology when I have something that works but I'm afraid I have to call a spade a spade here ... the .Net approach is outstanding.

-Max :-)