Why upgrade from VB6/SQL2000 to VB.NET 2008/SQL2008?

  • Thread starter Thread starter rcook349
  • Start date Start date
R

rcook349

I have a friend who's small company is on VB6 and SQL2000 for their apps.
They would like to know what arguments (high level) there are for upgrading
to the current version/platform of VB.NET 2008 and SQL2008.

Saying "newer/better/faster" isn't a strong enough argument when the counter
to that could be "if it ain't broke, don't fix it".

Does anyone have a few bullet points that make an argument for upgrading?

Thanks.
 
I have a friend who's small company is on VB6 and SQL2000 for their apps.
They would like to know what arguments (high level) there are for upgrading
to the current version/platform of VB.NET 2008 and SQL2008.

Saying "newer/better/faster" isn't a strong enough argument when the counter
to that could be "if it ain't broke, don't fix it".

Does anyone have a few bullet points that make an argument for upgrading?

Thanks.
Click to expand...

These are for upgrading to .NET only:

1) Your staff, or the staff you plan on hiring, are proficient in .NET
and not VB6.
2) You plan on launching a web application and you would prefer to
have the website (easily) use the backend libraries. I wouldn't
recommend using old VB6 dlls from an ASP.NET, though that's mainly a
personal preference.
3) You would like to use EF / DynamicData / ADO.NET Data Services /
Castle / Nhibernate / Rhino.Mocks or one of the many other .NET only
(well, mostly) tools. Entity Framework for example could be used to
abstract your entire datatier, making the backend database(s) even
less important.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
rcook349 said:
I have a friend who's small company is on VB6 and SQL2000 for their apps.
They would like to know what arguments (high level) there are for upgrading
to the current version/platform of VB.NET 2008 and SQL2008.

Saying "newer/better/faster" isn't a strong enough argument when the
counter to that could be "if it ain't broke, don't fix it".

Does anyone have a few bullet points that make an argument for upgrading?

Thanks.
Click to expand...

in order of importance :

Support ( VB6 and SQL 2000 are in obsolete fase ) , connectivity /
extenddability to other systems , maintanabelity ( VB 6 and SQL 2000
knowledge will fade away )

i have currently rewritten all my VB6 , VB.Net 2002 , 2003 , 2005 projects
to 2008 for the above reassons
we are currently playing with SQL 2008 ( our current DB is a SQL 2005 DB )



HTH

Michel Posseth [MCP]
http://www.vbdotnetcoder.com
 
Hi,

As I am now busy with an old VB6 application, every thing takes at less 3
times the time as needeed as with a version 2008, simple because in the
newer versions a lot of things are automaticly done for you, while the code
is more logical.

For VB6 it becomes almost impossible to get correct information for things
that are now common, while that was not 10 years ago.

There is a lot more, however all based on facts, that things which are now
common, where not 10 years ago. By instance the integration with mobiles,
Office, Internet etc.

Cor
 
I would add that if you want to target Vista or any any newer OS, I don't
think that SQL 2000 is going to work.
 
Gillard said:
vb6 can only target 32bit platform
Click to expand...

Coming from the other side of the tracks here... but, really... If it ain't
broke *don't* fix it.

If you're not writing new apps, there's no reason *at all* to migrate...
note that I say "migrate" and not "upgrade". Considering the dog/slow IDE
and the "everything including the kitchen sink - except VB specific
debugging utilities" approach to the environment... and the fact very little
code you have now will migrate without inspecting each line carefully, I
certainly wouldn't attempt to try and migrate any projects to a "less
friendly for VB" environment. (dotNet fans, save your typing, I'm not
talking about the LINQ, etc bandaids that *clearly* aren't based on the VB
language - I don't do database apps. Period)

"newer/better/faster" would only apply to "all new" development... and, even
then, if you're talking about desktop apps and haven't hit any limitations,
why bother.... besides, the jury's still out on the "better/faster" part...
no one's convinced me that dotNet's faster at *anything* and it's been out
for what.... 8 years now?.. and "better" is purely a matter of opinion...
personally, I don't like the environment. Since I've mentioned my gripes
many, many times, I won't bother now.
 
For a commercial product (VB6, VB.net, Java, C#...)

ADO.Net blows everthing else out of the water for performance and
functionality (depending on hardware of course) of data manipulation
against any RDBMS (sql server, Oracle,...)

If you have too much time on your hands - you could always write your
own data processing system specific to your situation in something low
level like MFC which could outperfrom ADO.Net. But for out of the box -
I have not experienced anything else that has the level of functionality
and performance as ADO.Net. But to use ADO.Net you will need either a
C# or VB.Net platform.

I haven't played with Java for a while. They may have adapted something
like ADO.Net to their platform (Just like MS stole a lot of .Net stuff
from Java).

But in MS terrirtory - I have not seen anything that could outperform
ADO.Net (.Net in general) against server based data systems (or file
based systems for that matter, text files, Excel, Word). The
Datagridview is the complement to ADO.Net. There is no way you could
create a subform in VB6 that has the level of functionality as a
datagridview - or at least with the same amount of ease.

Rich
 
Are you maintaining the code? Or is it stagnant?

If you're not making changes.......then don't convert it.

If you are, then you have to make a choice.
The cost of software is not development, its maintenance.

DotNet isn't going to help you if you bring bad VB6 practices with you.

Design Patterns (OO concepts) will help you create more maintainable code
as well.
Check "Head First Design Patterns" and/or www.dofactory.com for some intro
material.


You don't have to go VS2008/Sql2008 as your only option.

VS2005/SqlServer2005

VS2005/SqlServer2008

VS2008/SqlServer2005

VS2008/SqlServer2008

Those will work as well. If you're going to take the plunge, than
VS2008/Sql2008 would probably make the most sense, but I havent' looked at
the prices for licensing recently.

......................
 
Back
Top