Printable View
Hi
We have a small visual basic 6.0 application with an Access DB that we would like to migrate to modern code and architecture. I am not technical, but I am believe this would be something like a .net framework with a SQL Server DB.
What I am wondering about, is there any way to covert this code to a modern language/architecture? If so, what is the easist modern language to migrate to?
Paul
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
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
Since the new application would be very different in the communication aspect anyway, I'd agree with tg and say to do a rewrite. Try to recycle the parts that you can, but stay clear of automatic conversions or you'll end up spending more time trying to fix the converted code than you would writting it from scratch.
Best way - Start from scratch... treat it like new development. New requirements, new design, the whole ball of wax. Trust me on that. It's far easier. Otherwise all you're going to do is simply upgrade your problems from one platform to another. This is a chance to fix all the things that are wrong with the current app, add in a few new goodies for the users (maybe stuff they would like to see added).
As for on going support of VB6... that's actually hard to say. The old VB6 group is a very vocal group (trust me lobyists in DC have NOTHING compared to the VB6 camp)... originally it had been rumored that even Win7 wouldn't support VB6 apps... and, well, that's not the case.
Point is - take time, do it right, build from scratch. As I mentioned, there will be some cases where you'll be able to copy your old VB6 code and paste it into VB.NET and use it as is (maybe with some minor tweaking). Just don't try to run the app through the conversion wizard.
-tg
Any recommendations as to the architecture? As said, we have 40 smaller non-profit agencies that would need to access one central application/database. It is a small case management system, not a lot of data stored (difficult to estimate data per day).
In our current system, we also output reports to Excel and Word using local PC copies of these programs. I am not sure how this would work in a new environment.
So I take there is no real way to leverage the existing code base in a new architecture?
Paul
To add to the point, I think the conversion wizard isn't even available in Visual Studio 2010.
Depends on what the code does and how it's written, but probably not. What you'll find when you start with VB.Net is that the syntax is very different in some aspects, but a lot of things will be much simpler. For example if your application worked (read/write) with the Registry, in VB6 you had to code a lot to make the functions to do that, but in .Net that's already given to you, it has native support for creating services etc. Regarding Office integration and automation, I don't think you'll have any problems with that once you move to .Net.Quote:
Originally Posted by Paul-NYS
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.Quote:
Originally Posted by techgnome
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 :-)
Hi Paul,Quote:
Originally Posted by Paul-NYS
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 :D
"So I take there is no real way to leverage the existing code base in a new architecture?" -- as I've mentioned, at best you might be able to borrow bits and pieces of the existing app... but as you can see from the comments, it should be few and far between.
From a generalistic view, this is probably how I would design the system:
1) Use SQL Server - that's probably going to be the biggest cost.. since you're going to have a number of outside people connecting to it, it's best to go with something that can handle large amounts of connections and is stable and secure in a multi-user environment. Other options include Oracle and maybe MySQL.
2) Set it up on a server. Immediately lock it down. A good DBA should have no trouble with that.
3) Get a network administrator to ceate a VPN connection point.
4) Develop the app to talk to the SQL Server (or which ever db server you go with).
Now, here is where all that setup comes into play.
5) Install the app on the client machines
6) In order for them to connect, establish a VPN connection to your server
7) Once connected, they essentially they become part of your network (the net admin should understand this and ensure that proper security is in place so they can't get to places they shouldn't)
8) They should then be able to run the app and connect to the database.
An alternative is to move the database server into an area known as the Extranet... where it sits inside your network (where you can get to it) but it also accessible from the outside (where the other locations could get to it)... requires a bit more security on the server, but then you don't need the VPN connection at that point...
There are a number of way to handle it ... you could set up a webserver, and then build a web app... users would access it via their webbrowser.
-tg
This is all good information. A few follow-ups:
1. What is the difference between VB.Net, ADO.net, and .net architectures?
2. Some mention developing the future appl. in VB using SQL server. What is the difference between developing a future appl. in VB and the old code written in VB6.0?
3. Using .net/VB.net/ADO.net, there are client and web browser user interface options?
4. Using either the client or browser user interface approach, what software is required on the user's PC?
5. Outside of SQL server, what hardware/software is required to be purchased for both development and end-user usage?
Paul
1 - that's a bit of a loaded question VB.NET is the Visual Basic implementation layer on top of the .NET Framework (you'll see posts with FW followed by a number. FW = FrameWork... the number that follows is usually the version 1, 1.1.2.0, 3, 3.5, 4 ... 4 is the most recent.,.. 2 is the most commonly deployed) ADO.NET is similar to ADO in VB6, in that it is the basic Data Access set of classes for creating connections and running queries. BUT it is very much different than Classic ADO. In addition, there are different ADO.NET implementations (SQLClient for SQL Server MySQLClient for MySQL, ORAClient for Oracle, and so on).
As for .NET Architecture... that's more of a philosophy than an actual technology. It's a combination of treating everything as an object, disconnected and separating you layers from each other.
2 - well as you noted, VB6 may not run on future Windows versions. Also, advances have been made in hardware that are possible in .NET that you simply can't do (or if you can it is very hard, very messy, and unstable) in VB6 -- Parallel processing for instance. Multi-threading is another.
3 - For that you would look at ASP.NET... the server side components use .NET, be it C# or VB and ADO.NET. Depending on how fancy you want to get you can then extend it with Silverlight and give the user a fuller/richer experience.
4 - It's a web app... so a web browser. If you go with Silverlight, IE and FireFox should be able to handle it w/o issues.
5 - depends. If you go with the web app, then you would need a webserver capable of running ASP.NET - which means running a Windows machine with IIS (Internet Information Server) and the appropriate version of .NET installed.
-tg
Hi
Three other questions:
1. Is there a difference between the old VB 6.0 and the VB that is being used in the .net architecture?
2. Can an application developed using C# in the .net/ASP.net architecture be used with an Oracle database?
3. Is there a big difference in ease of development and/or quality in using a SQL server DB rather than an Oracle database in .net?
Paul
1. There is a difference, but how big it is depends on individual tastes and experiences.
Many people can happily switch from one to the other with no significant problems, but others decided in advance (generally without a good reason) not to like .Net, and therefore refuse to use it. In lots of cases it is easier in .Net to get the same work done, so programs typically take less time to write.
2. Yes, but I think you need to download something from Oracle (a .Net provider/connector perhaps?).
3. From my limited understanding (haven't used Oracle with .Net), SQL Server is a bit easier because it is also a Microsoft product, and is therefore integrated into the VB editor to some degree.
Is the VB that is now used in .net also endangered of becoming obsolete as VB 6.0?
Paul
Eventually, but not for many years.
VB6 was known to be "end of life" for Classic VB when it was released way back in 1998. VB.Net replaced it in 2002, and as yet there are no signs of .Net getting close to end of life (I'm fairly sure there will be a new version of it in the next two or three years, and possibly a few more in the years after that).
VB.Net goes obsolete roughly every 2 years.
Native VB went through a similar catabolic cycle until it reached its pinnacle at VB6 in 1998 and further developments were never released to the market. So in a way VB6 developers enjoyed a sort of "golden era" of stability from 1998 to 2005.
If you develop in .Net you will find that there is a strong current pulling you to pay (and pay, and pay) for rewrites and updates every new cycle. You can resist it for a while but if you wait too long you will face the same sort of legacy code problem you have with your VB6 code now. Bringing .Net code forward is no easier or cheaper than in any other environment. This is why lots of large shops have people stuck using VS 2003 today supporting ASP.Net applications that will probably never be rewritten in a newer version. I work with three guys trapped in that very ghetto.
If you're an Oracle shop it makes at least as much sense to consider looking at Java as it does .Net, and probably more.
I disagree with your usage of the word "obsolete" there... while a new version is released roughly every 2 years, the old version is still supported (unlike VB6), and is only slightly different to the new version (unlike VB6 to any version of .Net).
While upgrading an existing project from one version of .Net to another isn't guaranteed to be 5 minute job, I have serious doubts about it being near the level of upgrading VB6 code to a more modern language.