Fw: Accessing FP data from external programs (MS Assess)

[Brian K. White]

----- Original Message ----- 
From: "Bob Stockler" <bob at trebor.iglou.com>
To: "Filepro List" <filepro-list at seaslug.org>
Sent: Saturday, November 12, 2005 9:06 PM
Subject: Re: Fw: Accessing FP data from external programs (MS Assess)


> Phil Hausman wrote (on Sat, Nov 12, 2005 at 08:19:02PM -0500):
> [snip]
>
> | Thanks to those who responded and sorry to those who I apparently 
> confused.
> | Let me try to make the question much simpler.   If I have a prc table 
> that
> | assigns a value to variable aa and that value is "smith", is there a way 
> to
> | have that value returned to the unix command line when the prc table is 
> done
> | running so that I would see the following:
> | # /appl/fp/dreport myfile -f myprc -s recordone
> | # smith
>
> My answer is still the same.  ISFAIK. filePro's SYSTEM command does NOT
> return anything of use to you within a processing table.
>
> If you are on UNIX, look at the USER command that lets you establish a
> 2-way pipe between an OS program and a filePro process.

When he said system() he meant other languages besides fp could run fp in 
their system() command and thereby get data out of fp.

The answer is it's kind of klunky and kludgey but we all do it various ways 
anyway since there is really no choice. fP just has no real, proper, 
non-interactive mode. We wrap it in scripts and capture it's screen output 
to /dev/null, and variables like pfmbto have been added to help, but it's 
still just kludges to get what you want out of something that doesn't 
provide it natively.

My previous post was a basic example of what he asked for. fpsql, fpweb, 
onegate, and I'm sure a host of miscelaneous home grown things we've all 
probably done work similarly.

Really what he wants is a script that first does something like what I 
posted which exports data to a temp file, then cats the file after rreport 
exits, then deletes the temp file.

Possibly, since he happens to be on unix, possibly he could eliminate the 
script and do it all directly in one fp process by having fp write to a 
named pipe instead of a plain file and is parent process could read from the 
pipe. You could replace the export command & named pipe with a user() 
command running netcat and get the same thing across a network too, though 
I'm not sure how you'd kick it off since presumably the remote machine would 
want to initiate requests. Back to the cgi idea for the simplest way to do 
that I think.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!