forums.silverfrost.com

Little-Acorn · Joined: 06 Jul 2008 Posts: 111 Location: San Diego

I've written a large program which, upon startup, will have to open a file on one disk drive (a remote one on our system), and copy it to another disk drive (the local C: drive on the computer the program is running on).

I can only access the remote file by using the ATTACH@ routine. I have experimented with ways of doing that, and it works well.

But for various reason I cannot just read in the entire file, then turn and write out the entire file. Instead I must read in one line (approx. 200 characters, it varies) from the remote file, then write that line to the file on the local C: drive, then read the next line from the remote file, then write to the C: drive etc.

Is there a way of doing this without ATTACH@ing the remote file, opening it, reading one line, closing the remote file, ATTACH@ing the local file, opening it, writing the (single) line, closing the local file, ATTACH@ing the remote file, opening it again, reading past the first line and reading in the second line, closing the remote file, ATTACH@ing the local file, opening it in APPEND mode, writing the second line to the end of it, closing the local file, ATTACH@ing the remote file, etc. etc.?

In other words, is it possible for me to have a file on a remote drive open for reading, and a file on a local drive open for writing, at the same time? (When I have had two files on the same local C: drive, it has been easy to have both open in this way. But what about one on the local C: drive and the other on the remote Z: drive that needs an ATTACH@ statement?)

There are 10,000 lines or more. It seems like a huge amount of overhead involved in transferring each line. But is most of that "overhead" really just a few bit flips, which don't take much more "real time" than it would take to copy a local file to another local file with no ATTACH@'s, and just one OPEN for each file, then read,write,read,write, etc.?

If there really is a lot of overhead in the method I described, then is there any more streamlined way of doing this?

--------------------------------------

A related question: How big is the clipboard? Would it be possible to use the READ command and then the COPY_TO_CLIPBOARD@ command many times, to copy the enitre 2GB remote text file to the clipboard? And then use the COPY_FROM_CLIPBOARD@ and the WRITE commands many times, to write the entire file from the clipboard to the local file?

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I may have missed your need for ATTCH@, but you should be able to open the files, giving their tree name, without the need for attaching. I would expect the following example should work in most cases:

Little-Acorn · Joined: 06 Jul 2008 Posts: 111 Location: San Diego

Well, now I feel dumb. The remote drive is mapped as the Z: drive, and I had tried several methods of doing a directory search on Z: using front slashes, back slashes etc. None seemed to work.

And now I just tried a few more, and bingo, one worked.

So this whole thread addresses a problem that (it turns out) doesn't exist.

My apologies for costing you a lot of brain cycles over it. You fellows keep helping me no matter how dumb my questions are.

As Master Shifu said, there is now a level zero. (Can you tell I have a 5-year-old and 13-year-old son?)