Re: HELP: UNLOAD TO stdout

Mike Dobbert, molten keyboard in hand, chimes in with: > > I am attempting to modify a 4GL program in which an SQL statement is > executed. This is done using the UNLOAD TO statement as follows: > > UNLOAD TO szFile szSql> > The SQL statement is in 'szSql' and the results are stored in the file > specified by 'szFile'. Is it possible to execute an SQL statement and > send the results to 'stdout' or a pipe, or a socket, or some other file > descriptor? > > One solution would be to simply copy the contents of 'szFile' to 'stdout' > or a pipe, but that seems somewhat inefficient. Is there a 4GL statement > similar to UNLOAD TO that might do what I want? The problem is that 4GL does not make stdin/stdout available to the programmer save through PROMPT and DISPLAY (and for your purposes, the phrase "Yuk!" comes to mind regarding these). You can write a report out to SCREEN or to another program, and that will work as well. Another option is the use of a named pipe, but this will depend on which UNIX you are using. On my system, this would work: DATABASE test MAIN # This creates the actual named pipe, check your man pages for your system. # I'm running Unixware which is an SVR4. Most folks don't have # /etc in their path, and that be where 'mknod' lives. RUN("/etc/mknod my_pipe p") # Let's compress the unloaded data. Note that this is run FIRST, # and the 'cat' will wait for something to come into the named # pipe, so it will wait for you. If you forget the WITHOUT WAITING # then you'll be stuck here until the cows come home. What? No # cows? You see my point then... RUN("cat my_pipe | compress > unload.Z") WITHOUT WAITING # The UNLOAD will open the pipe just like any other pathname, and # simply pour the data down into it. The fact that 'compress' is # waiting for the data on the other end is meaningless. It could # be any program. It's best to have a program that will use all of # the data. I've never tried it with something that only wants # some of the data. I imagine the UNLOAD will burp, and error out # (just like if the file system were full). UNLOAD TO my_pipe SELECT * FROM HUGE_TABLE # When we're all done, we can remove the pipe from the system. RUN("rm my_pipe") # That's it! END MAIN You don't have to recreate the pipe every time if your don't want to, but make sure that only one person is using the pipe at a time, lest things get ugly. Informix sees my_pipe like any other pathname, so you can do this anyplace (like dbaccess). Just make sure there is something on the other end to get the data. Works hunky dory with "LOAD FROM" also. Have fun, and Good Luck! Will Hartung (villy@collinscomp.com)