Re: Foxpro

Hi David,

Grant is taking the right approach here.

Maybe try the tact of "it's better for his future to learn REAL SQL, on
a REAL concurrent multi-user database". Database servers have a good
long future in front of them unless something weird and radical
happens. Foxpro on the other hand doesn't have the same kind of future
beckoning to it.

His learning to do it in a non-Foxpro way (aka PostgreSQL) will be
beneficial for him.

Of course, that is if you want to let him take the time to learn
PostgreSQL that is. :-)

If not, there's a Jobs page on the techdocs.postgresql.org site where
the specs can be put for the kind of person you're after.

Regards and best wishes,

Justin Clift

Grant Johnson wrote:
>
> David Siebert wrote:
>
> >Yea I know I am the boss and I did make the rule. This person is a good
> >support tech and fancies himself a programer. I am trying to get him to
> >understand without saying "Because I said so" He is just so sure that he
> >right and all the other programers here don't know what they are talking
> >about. Oh well you have to admit that it is a nice change to see the
> >management of a company telling a wannabe programer "No you will not use
> >Microsofts program. You will use this opensource server instead."
> >-----Original Message-----
> >
> Foxpro is a successor of the old DBase series. It uses the file
> structure from DBase and Clipper. This was a fine format, however, it
> was designed with a different era, and different uses in mind. The
> format best fits single user systems. The relationships are not binding
> in the same way, and the metadata is not nearly as integrated. It did
> not support transactions the last I worked with it. It was designed for
> putting all of the data in one table, and the relational part was bolted
> on later, and not all that cleanly. The relation function is klunky at
> best to work with.
>
> As for the Foxpro language, which is VERY similar to Clipper (or at
> least was in version 2.6) has a very dificult time supporting one to
> many joins, a fundamental part of normalized relational data. Whatever
> you do, don't try to understand what it is doing in the case loops it
> generates for event handling, you will hurt your head. This makes the
> code unmanageable and unmaintainable.
>
> Foxpro tries to be everything. It is a gui designer, an application
> language, and a database backend all in one package. This can be nice
> for a small project, but as soon as it grows, and live backups and
> multiple concurrent users become an issue, it falls down.
>
> PostgreSQL is, on the other hand, just the data backend, but rather than
> being simply a file like Foxpro or Access, it is a service running in a
> central place to allow concurrent requests, and resolve conflicts. You
> will still need something else to generate the front end interface and
> most of the logic. Since this is a newbie, I highly reccomend PHP. It
> is easy, graphical, and gets results very quickly. It can quickly give
> a sense of accomplishment, while still being strong enough to develop
> real applications with later. Then he can learn Java, and start the
> other applications. Just imagine the joy of being able to program in
> any one of MANY languages, by MANY users, and get the SAME data from the
> SAME source at the SAME TIME.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi