Josh schrieb: You haven't specified where your main pains are. Do you have at least rudimentary architecture ? How often do you have code reviews / refactored your code ? Have you been striving for good code ? Is it a total mess ?
Guessing only from the number of screens, you probably have more than trivial amounts of data. *Based on that assumption*, I'ld move the data FIRST. Get rid of the JET engine! If you are certain you will have to support SQL server, make it SQL server and MSDE/new express version first. Only then (perhaps) think about adding a totally free database engine. If not, take your pick but *move the data*. While you are on it, refactor the old code into something at least resembling a 3 to 5 layered approach with COM. Doesn't need to be perfect 100%, but more than 50%. Then exchange the parts that benefit the most by implementation inheritance, since VB's interface inheritance is arguably the "best" technical reason for redundant code. I'ld guess the business layer[s] would be the next things to convert - but if your VB-forms are mostly slightly augmented copies differing only slightly, the GUI actually might benefit most from a rewrite, if the business rules are written redundance poor. One of the typical scenarios asking for GUI inheritance is insurance - customer data is only specific for few fields and even policy field groupings resemble each other across similar policies. A "minmally redundant" business layer could even in VB be implemented without too much sweat- for instance by having methods overwritten in a inheritance based OOP - design as name mangled methods on objects responsible across similar problem domains, keeping the "common" methods clean. Check your code with a critical eye - even code forced to be totally OOP for technical reason=langauge can be written across a wide spectrum of quality. If there is nothing which is good enogh to be converted last or no segregation/layering at all in the current program, (even if it came from the DOS dinosaurs, there were "good coding practices" known - some of the old "libraries" were better decoupled than modern day OOP class libraries.) get rid of most of the people responsible and start only then. my 0.02 EUR thomas > We have a program written in VB6 (over 100,000 lines of code and 230 UI > screens) that we want to get out of VB and into a better language. The > program is over 10 years old and has already been ported from VB3 to > VB6, a job which took over two years. We would like to port it to > Python, but we need to continue to offer upgrades and fixes to the > current VB6 version. Does anybody know of ways we could go about > rewriting this, one screen at a time, in Python, and calling the screens > from the existing program? > > We are also looking for a graphics toolkit to use. IronPython with it's > .NET bindings and ability to integrate with Visual Studio looks good, > but leaves that bad MS taste in the mouth. > > We currently use a MS Access back end and need to migrate to a proper > SQL server. We need to leave options open for SQL Server (for customers > who want to use existing infrastructure) and something like MySQL or > PostgreSQL. But in the mean time, we need to be able to access an > MSAccess (Jet) database from Python. > > Any answers/suggestions/pointers are greatly appreciated. > > Thanks, > > Josh Isted -- http://mail.python.org/mailman/listinfo/python-list