What does the migration look like for moving an existing ADO VBasic 6 Client solution using SQL Server 2000 look like and will it remain largely compatable on the server end with SQL server 2005?
We are looking at moving it to .NET for Studio 2005, and i am concerned about massive recoding on the client side to deal with security issues between Server 2000/2005 and 2008.
If you're taking the leap from vb6 to .Net, then yes it's a leap. It will require full recoding with the exception of queries.
This is why detailed and accurate documentation is an ethical imperative. Without it, look forward to 6 months of investigation before you even begin to think about the code.
P.S. There are code converters floating around that will traspose the code but I can't comment on their accuracy.
Adamus
|||
jason.bronner wrote:
What does the migration look like for moving an existing ADO VBasic 6 Client solution using SQL Server 2000 look like and will it remain largely compatable on the server end with SQL server 2005?
We are looking at moving it to .NET for Studio 2005, and i am concerned about massive recoding on the client side to deal with security issues between Server 2000/2005 and 2008.
If the issue is VB6 going against SQL Server 2005 there should not be any significant issue there. Test it obviously, but most code should run just fine. As to the migration to .NET, yes, that is a much bigger leap, but the leap is an issue regardless - it's not just an ADO vs. ADO.NET thing. VB.NET is a different animal than VB6 (heck, many VB6 developers actually find it easier to go to C#), and VB6 to C# has obvious issues too. Such a migration is a good time to look at your approach, as straight porting of code may not make any real sense. How you want to arrange components, differences in data access, differences in how interfaces work vs. COM, and a host of other things are reasons to rethink your approach to the appllication.
