Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

cannot create file using copy file command

Status
Not open for further replies.

dougerstew

Programmer
May 30, 2003
54
US
i've seen other instances where people have gotten the cannot create file error, but none i found were similar to mine. I apologize if i've missed it.

i use the command COPY FILE "U:\labelvfp\test.txt" TO \\fserver\t6215-new to print to a dot matrix printer. it works fine from my laptop. But on other workstations it gives the message "cannot create file t6215-new". Can anyone tell me why this is happening and how to fix?

thanks
doug
 
I always ask two questions first: 1) Did it work before? 2) If so, what changed?

I also always ask what version(s) of Windows everyone is using. Anything after XP is severely limited (by default) about file creation in certain locations, but before suggesting that as a cause we'd need to know versions. Is there any correlation between those that work and those that don't?

COPY FILE is a pretty old (i.e. from DOS) way to print a file. Have you tried other ways?
 
Thank you for the response.
Everyone is using Win 7. i'm printing to high speed dot matrix printers. using label form causes the print to be illegible due to using windows fonts. using copy file prints just as fast or faster and the print is 100% more legible. My laptop has vfp installed on it. I've created an exe for the others to use. It did not cause this program using the label form command, but numbers were very hard to read on the labels.
 
Well, you didn't answer dans question, but my guess is missing permissions to \\fserver and/or the printer.

To judge, if that's making sense it's essential to know if it worked before and what changed. If Win7 was introduced lately it can easily mean the windows profiles were renewed and users have to be permitted again.

Bye, Olaf.
 
The usual reason for this sort of error is either a permissions issue (not having Create or Write permissions for the target directory), or the target file already exists and is open in another application.

Regarding your statement that "using label form causes the print to be illegible due to using windows fonts" ... I'm not sure what you mean by "windows fonts", but my first reaction would be to find out why the print is illegible, and to do something about it. Report and label printing work perfectly well in VFP with all kinds of printers, including dot-matrix printers. Even so, if the only solution is to use printer-resident fonts (as opposed to "windows fonts"?), then that's perfectly possible as well, without having recourse to a separate print file.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Using Windows fonts" is something YOU control, you know.

It sounds to me like that printer hasn't been installed properly, or perhaps you should use the Generic Text driver for it.
 
thanks for all the feedback. Mike, you wouldn't believe how many countless hours i've spent trying to make the fonts available in VFP work to print to my Tally T6215 and T6092 printers. Each font in combination with the label form either prints out of alignment or not legibly enough. The current program is living with the legibility issue but our people or getting more and more negative feedback. I'm already printing to these printers through label form. how could permissions be the issue using copy file? the fonts resident on the printers itself is great. it's just how vfp interacts with them through label form that seems to make it hard to read.
 
Like mentioned above, it is most likely a permissions issue, but there may something else involved here too. Maybe something funky with the server name, or maybe backslashes.
Are you trying to copy the file to \\fserver\ as "t6215-new" or as "t6215-new\test.txt"?
If it's the first one, you may have to use a "." for the filename:
Code:
COPY FILE U:\labelvfp\test.txt TO \\fserver\t6215-new[COLOR=red].[/color]"

You may have better luck using "_" instead of "-" in the filename.
Code:
COPY FILE U:\labelvfp\test.txt TO \\fserver\t6215_new.

If all else fails, try strings:
Code:
STORE "U:\labelvfp\test.txt" TO cLocalFile
STORE "\\fserver\t6215_new.txt" TO cServerFile
COPY FILE (cLocalFile) TO (cRemoteFile)


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
thanks, Dave. I will try your ideas. I'm just curious if you would know why it would work on my laptop but not on the workstations of my users? Everything is set up the same as far as the printers go. The only difference I know of is the users don't have vfp installed on their workstations. They just use the exe to run the program.
 
yes, \\fserver\t6215-new is the name of the printer. Sorry i wasn't more clear on this command, and thanks for clarifying.
 
>How could permissions be the issue using copy file?

If you copy a file, you not only read it, which needs read permissions, but also write it. In this case to the printer device, which is handled as a file resource. The \\fserver indicates it's a shared printer on the computer \\fserver and you also need permissions to open a connection there.

Bye, Olaf.


 
the other workstations have been printing to these printers for a couple of years, so I would think they already have the necessary sharing permissions. What else am i missing?
 
What you're missing is that when they're printing to it from a workstation they have already opened a connection to that printer using a driver through some port. What you're are effectively asking VFP to do is "Copy this file to that thing", which as an analogy, could be a computer without specifying a hard drive.
I would suggest installing a 'Generic/Text' driver and do a 'Label Form ...' there, or even use the old SET PRINT TO ... with the associated '???' commands.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Did you use VFP for a couple of years, too, and this code? My guess is, you can only copy a file to a printer this way with DOS copy command, not with VFP COPY FILE.

You should try SET PRINTER TO NAME \\fserver\t6215-new
then use ??? to print directly

eg
Code:
SET PRINTER TO NAME \\fserver\t6215-new
??? FILETOSTR("U:\labelvfp\test.txt")

I haven't tried this at all and don't know if that's how the ??? command and SET PRINTER really work together.

Bye, Olaf.
 
i'll give your thoughts a try on Monday, and let you know how it goes. Thanks!
 
I believe you said that the workstations only have the EXE installed and the laptop has VFP installed. I wonder, and this is only something I'm throwing out there from my cobweb memory back in the old FoxPro DOS days (where I had many a printer issue like you're having and I resolved them - eventually); could it be that you need a FoxPro resource file on the workstations?
 
I tried installing a generic/text driver and it didn't like that.

then tried just typing in the command window
SET PRINTER TO NAME \\fserver\t6215-new
??? FILETOSTR("U:\labelvfp\test.txt")

nothing happened until I issued another "set printer to" command. then it printed as requested.

so I changed my code to include

SET PRINTER TO NAME \\fserver\t6215-new
??? FILETOSTR("U:\labelvfp\test.txt")
set printer to

Incorporating this in my code works perfectly on my laptop, but again not on the workstations. When I choose the printer, it now says "printer not ready". Also, before I choose the printer, it prints a couple of blank pieces of paper on the local injet printer.

Any other thoughts? it's hard to understand why the workstations act differently than my laptop. The exe file being used resides on the server along with all the vfp resource files.
 
i should also say that the blank pages were coming out while using the copy file command
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top