Hi,

I need to transfer the binary data from my D3/NT host to the remote
client. I know that I can use shell command to execute "sz" if I were
in Unix/Linux platform. I have already searched the net whole day but
can't not find any "sz" replacement for Windows Platform.

I have had no clue to solve this problem. What is the best method to
use?? I am using Accuterm as the remote client emulator.

Thx & Rgds,

Hey Sky,

If the data is in a single file, you can use the AccuTerm "FT" command from
the
command line to download the data to the PC. If the data is in several
files,
of if it's in a report, you will have to use one of two things.

1. Use AccuTerm's CAPTURE command - this can be done manually. Don't
forget to turn off capture.
2. From within your program, assuming the data can all be contained in some
type of
array, you can issue the download commands from inside a program and
AccuTerm will
honor them when printed. Works quite well.

If the data is perhaps a single item, you can use the D3 COPY command to
make
the data appear on the same server as D3 is running.

Assuming the file to download is "STUFF" and the item is "SPECIAL" and
you've got some
folders created on one of the drives under the D3 server, and perhaps it's
shared on the network,
you can issue this command


and that works pretty well also.

If this doesn't help, feel free to send me email directly and I'll be glad
to send you a
sample of something I have done.

Larry Hazel


"skypirate" <singdad (AT) singdad (DOT) no-ip.com> wrote

Hi Alfred !

Do the remote clients have a VPN connection to the server ? You may be
able to simply access data via a share on the server if so. Also, have
you tried using the BIN: driver with FTPICK ? I haven't but in theory
should be OK

I have some "commercial" options as well - we have used MailLynx to
sync remote, stand-alone databases in POS situations fr many years -
sending T-DUMPS pseduo-tapes as attachements. Also have a DataHub
facility under the "Visage" banner that we use to ship data around the
country between 'pick' and 'non-pick' systems, with ZIP compression,
password encryption etc

contact me directly if you want to discuss - rossf @ stamina . com . au

Thx Larry and Ross!

May be I should give the whole picture :-

I tried to send out a Postscript report to the remote client so that
they can print the report locally.

But the problem is... the file is 12meg+ or may be more (depends on the
seletion range) it will take a long time in some slow connection
office (128K or 256K).

I manage to zip it and the file will reduce to 1/10 size.


Problem 1. : FT won't support binary data
Problem 2. : the data need real time so can't be send via email


Rgds,

Zip it, MIME it, FT it, then use Accuterm to "ESC STX <" and un-MIME
it back to ZIP, un-ZIP it, then send it to the user's local printer.

An alternative to the MIME/FT process is to leave the file on your FTP
site, then instruct Accuterm to FTP the file into the user's PC, then
unzip and print as above. That might be faster but it does require
you to have an FTP server open to local and/or remote users.

Sure, the size will increase during the MIME and performance will take
a hit during the compression and file transfer, but this is the way
you've chosen to do it so this is how it has to work.

A method that might be more performant is to put report generation
code on the client and then pipe data into it. Crystal Reports or MS
Access would be good for this. That way you don't need to mess with
PS and you don't have to send gobs of data over the net.

Related to that, this is a good application for PDP.NET or mv.NET.
Once the data is available on the server, AccuTerm can fire-up a
separate dialog that can show the user with a progress bar that their
data is being downloaded and sent to the printer. This frees the
Accuterm session for the user to continue their data entry. Why use
..NET? Because it integrates well with Crystal Reports and many other
VERY impressive reporting tools, and data access is fast and stable.
Again you only transfer the data, not the visual attributes of the
report which is really just a lot of code repeated for as many pages
as you need. For examples of reporting tools, see:
Active Reports: http://www.datadynamics.com
XtraReports and XtraPrinting:
http://www.devexpress.com/Products/NET/XtraReports/
http://www.devexpress.com/Products/NET/XtraPrinting/

I think mv.NET might be best for this application because with the
large amount of data being transfered, the end-user might terminate it
intentionally or accidentally. mv.NET would probably hold up better
because it has a feature called "fetch on demand" which allows it to
pull up data in batches rather than trying to do it all at once. This
is in fact one of the benefits of ADO.NET and the distributed data
architecture. In this scenario, only a part of the selected records
would be called to the client, then as the client is rendering that
data, the connection to the server is free for someone else to use,
and the user can terminate the session without locking up the server.
The client code automatically picks up where it left off until all
records are processed. I need to check PDP.NET v3.0 to see how it
behaves in this regard. I can code up a sample of this synchronous
reporting method in action with mv.NET, but I'll do so only for
someone who's really interested in adopting the technology. Hmm, now
that I think about it, for an added bonus the same code can be used on
the server side just in case your user actually does want reports
generated and then sent to them.

Back on performance, if you're asking the user to print a 12MB file,
data transfer is only 1/2 of your performance problems - the user will
need to wait a good long time for the printer to load and render that
much data.

HTH,
Tony
TG@ yet another application for dotnetNebula-RnD .com

"skypirate" <singdad (AT) singdad (DOT) no-ip.com> wrote:

though some good suggestions have already been made, I just wanted to
mention that you can install cygwin (www.cygwin.com) on an NT machine
and have access to most of the command line tools that you're used to in
unix.

skypirate wrote:

Tony,

you are my man!!!

this is exactly what I am looking for.

Understand that the size will be increased by the MIME encoding but it
is still reduce 80%.

Once the Postscipt file reach the client side, all the data will go
into the windows spooler which will free the terminal for other usage.
(hoho, then it is not my baby anymore)....

Rgds,