>Hi Bob Lee,
>
>I took a look at the VFP SELECT SQL help in the VFP Doc. VFP has a top [expr] or [percent] function that can be a part of the SQL statement. When used, this would grab for example the top 500 matching records or top matching 10% of any SQL. This would put a top on the number of record included in any SQL. I then took a look for something similar in postgres. Postgres has a [LIMIT count] function that can be included in the SQL, so I added this to my VFP client app with a LIMIT 500. This would limit any SQL to a maximum of 500 records. Do you think this is about right for the purpose of a demo VFP client Front End to a PostreSQL Back End.


One of the reasons why VFP is being tested as a front end to PostgreSQL is its rich PEM set for its GUI controls.


PostgreSQL has PL/pgSQL, which compares somewhat with Oracle's PL/SQL. While Oracle has two package components that contains PL/SQL code, PostgreSQL uses FUNCTIONS to hold PL/pgSQL code, which is very similar to Oracle's.
http://www.postgresql.org/idocs/index.php?plpgsql.html#PLPGSQL-ADVANTAGES

The above URL mentions using pgaccess as a dev tool to create the triggers, functions, etc... I can testify that pgaccess works very nicely for that. While the PEM set for its dialog design mode is woefully weak, simple forms (tcl scripts run with wish8) are easy to create and work ok. All you really want is a form to accept data, simple edits, and then the ability to string the data up and send it to the backend, where all the heavy lifting is done.

Excellent examples:
http://www.postgresql.org/idocs/index.php?plpgsql-description.html#AEN24032

I mention that to relate what we are doing with Oracle, and will probably do with PostgreSQL in the future. We are moving away from VFP as a front end in favor of html pages incorporating Java that access data on Oracle. This will make us platform independent, and important goal.

We have a production app employing JavaScript in a test mode, and its users (about 40) are raving about it. They are running Netscape to add, edit and delete about 250,000 tax records on the Oracle backend, and to generate HTML reports via Oracle's HTML generation tools. Handwriting JavaScript HTML code for a GUI browser front end isn't as easy as VFP front ends. But, we are going to take advantage of the rich Java J2EE objects, and platform independent GUI RAD tools to write the future front ends. We use the browser and applets for user input edits before the data is strung up and sent to the back where packages, functions, triggers, etc... do the heavy lifting. In otherwords, there is no pocessing code in the front end, merely user interfaces and edits.

I have been experimenting with several platform independent GUI RAD tools: Visual Age for Java 3.x (IBM), Eclipse (IBM) and Forte (Sun). VAJ3 tends to be monolithic - you can't do what it doesn't do. Eclipse is missing the WYSIWYG form design and looks more like a C++ RAD tool. Forte has a nice form design and you can connect to CVS (Concurrent Version System) automatically to track code changes. Currently, I favor Forte the most. Its PEM set is not as rich as VFP, but most of the heavy lifting will be in the backend anyway. Just condition the inputted data, string it up and send it out, receive the result set and display it. All the work is done on the back end.

The way W2K is being pushed into XP, which will be pushed into LongHorn and its viral Object File System, our IT head says that we can't afford to go there and security concerns won't allow us. .NET/Passport/HailStorm (or what ever the latest alphabet soup is) can't be used to store tax data, period. So, between now and then we are preparing for the move.

Someday, within about five years, a single CD set of a Linux distro is going to supply the server OS for the Oracle backend, the OS for the client frontend, the source of J2EE runtimes and probably the GUI RAD dev tool. The office App will most likely be StarOffice, which we are already using. I am not even sure Oracle will be part of the mix. PostgreSQL is offering the promise of being able to drop an EXPENSIVE backend with an odious license, just as Linux is allowing us to drop and EXPENSIVE front end with an odious license.

Total cost for 300+ workstations and about 30 servers: $100.