Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Salisbury <KSalisbury(at)twinman(dot)com>
Cc: Postgresql Novice <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux
Date: 2012-04-16 14:08:25
Message-ID: CAHyXU0ygcquV2Q+ofaaL43dZf1aCg7WurjQp2qCt=fcexYL3ZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

On Fri, Apr 13, 2012 at 10:41 AM, Kevin Salisbury
<KSalisbury(at)twinman(dot)com> wrote:
>
> We are in the early stages of planning a migration of all our VFP 9 databases to Postgresql. Our VFP dbc contains roughly 300 tables and 8GB total data. Screen replacements are likely going to be HTML5/CSS3 based and report replacements will likely be one of the open source BI reporting portals. While we know VFP very well, and we use a LOT of linux elsewhere in the company - we know very little about Postgres. We do see a lot of tutorials out there for new Postgres databases, but not much in the way of migration from VFP. We're curious to know if anyone else has gone through a similar migration that may have some advice on how to get started.

I started out in foxpro and ended up in postgres. IMNSO, you're making
the correct choice. In my case, I didn't go 'full web' right off the
bat but went to a delphi-postgres thick client approach which remains,
even today, the most efficient method of developing applications ever
invented. There's a lot of ways to do web applications and how you
do it will probably be a bigger mental switch than the backend
database. Postgres can fortunately duplicate most of the things
foxpro can do (in my case, it was functional indexes) and once you get
used to the SQL paradigm things will feel easy, natural, and elegant.
Being foxpro guys you'll probably be writing a lot of stored
procedures (plpgsql, while quirky, is great for that) and keeping a
lot of logic in the backend which is a good approach.

On the web side, I would tend to avoid all technologies that employ
scaffolding, or auto-generation, of either the html or the sql.
Learning jquery is a fantastic choice for your client side javascript
and it will open the door to many fantastic free/commercial rlibraries
like jqueryui, jstree, highcharts, google maps, and the up'n'coming
google charts. Take a very strong look at the new postgres json
support (http://people.planetpostgresql.org/andrew/index.php?/archives/255-JSON-for-PG-9.2-...-and-now-for-9.1!.html)
and how it can efficiently tie into json receiving javascript
libraries.

On the BI side, you can either do an ad hoc java script based solution
or employ a reporting framework. If you want to go full framework then
your best options are probably in the java side of things. The best
of class reporting solutions are probably jasper for classic reports
or Pentaho Mondrian for full BI. I prefer full javascript, but it's
totally understandable if you want to use a framework especially if
you want to make a heavy investment into java. There's also the
expensive Smart framework which can either be used directly or via
java through the GWT. Speaking of the GWT, while I think it's great
for a heavy java team, I think you'll get more mileage out of
javascript/html5/css if you're starting from scratch. Anyways, good
luck.

merlin

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Kevin Salisbury 2012-04-16 17:33:45 Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux
Previous Message Kevin Salisbury 2012-04-16 13:16:43 Re: Visual FoxPro (VFP) 9 Migration Strategy to Postgresql on Linux