>>We have a legacy system that we are currently re-designing. However, as a stop-gap measure, we began using the CopyFile API function for sending print jobs to Novell queues. Our print jobs are printed to file and a post-processing routine then takes the file and, using CopyFile, redirects it to the print queue on the Novell Server.
>>
>>However, just last week we ran into our first hang up. After a bit of sleuthing, we determined that the CopyFile function will not deal with files larger than 64k when used on a Win98 machine. We can print the exact same file from a 2000 machine, but trying from any 98 machine yeilds an error.
>>
>>Does anyone know of a workaround for this. We only have a few users at our site that deal with printouts that large but they still need their printouts all the same. (Have you ever tried to tell an accountant they can't have a general ledger report because it's too big?) 8?)
>>
>>Anyhow, any help you can offer would be greatly appreciated.
>>
>>Thanks in advance,
>>
>>Rodd Harris
>
>Rodd,
>I wouldn't think this would be a problem. People copy large files all the time on Win98 systems without problems. It doesn't sound like a CopyFile problem. What is the error number returned by GetLastError:

>declare integer GetLastError in kernel32

>
>Maybe it is a problem with copying it to the print queue and something could be done on that end.

I agree that it's not a Win98 issue; my guess would be that it's a NetWare Client issue. The easiest/best solution would be to use something like my DIRPRTCLASS (in the Files Section) that interacts at the spooler level rather than at the file system level to queue the file, rather than relying on being able to write directly to the queue with CopyFile() (I wrote it initially to deal with problems some Novell clients had in directing output to mapped NetWare print queues) and the SpoolFile() method should address things pretty nicely.