KAM.covad wrote: > I have a very large vfp9 sp1 application with 4 dbc's and hundreds of tables > in 4 different folders, all linked into a single > application. All tables are linked using integer primary/foreign keys. All > tables get the next primary key from a separate 1 record > table with the same name. All the data entry screens use an object (scatter > name) on the form as the data source for the textboxes. > When data is entered/changed, that object is 'gathered' into a local view > which updates the table. > > I would like to keep as much of this design intact as possible because it > works well and is very easy to maintain for an > application this large. > > I would like to convert all this to dabo/python/postgresql by 2012 if > possible. I want to be able to run on Windows and Linux and > maybe even Apple depending on the market. I am getting more requests from > clients about running on Linux. > > Has anyone done anything like this and/or beginning to work on it? Is there > some 'canned' way to convert vfp9 data tables into > postgresql and use the dabo framework so that it would allow me to view > records, create some sql, etc for testing? And then > possibly > create some simple data entry screens just to prove some design concepts?
I would suggest dividing up this task into manageable chunks. Your 2012 target sounds doable if you commit resources weekly to this. I would seriously consider starting out by converting your VFP data to Postgres, and connecting the VFP app to Postgres. This was the strategy I used when converting my main VFP app from local VFP tables to MySQL back in 2000-2002. Once I had the data in a real server, I could maintain the VFP app while experimenting with other environments for creating applications against that same data. Once the data is in Postgres or some other supported backend database, there's a canned "Application Wizard" which can serve to give you ideas or even a jumping off point for your app. My current commercial app started out by me defining the data structure, importing some test records from a different system, and running the AppWizard. I then modified the generated code, augmented it, building from there. The benefits of the AppWizard include getting started quickly to a deployable app, and a scalable structure. But you must treat it as a jumping-off point only. One of the cons is that you may feel boxed in by limitations of the AppWizard design if you aren't willing to figure out how to modify and add to the code to make the application "yours". I would also suggest perhaps budgeting for some consulting/assistance from some of us here. There's converting your UI, converting your business rules, and converting your database. Then there's putting it all together into a deployable app on each target platform (you'll want to target Mac, too). Each of these will be a large job, and you'll want good guidance to avoid fighting the framework as you learn. An exciting prospect! Dabo is up to it, I'm confident of that. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
