DoCmd.OutputTo on Networked WiFi Drive?

[elturbo3]

Microsoft Access 2010
Windows 7 Laptop with LAN
Ipad with pdf expert wifi drive

I'm using a simple access database comand button to select and export a single record in pdf format to a predetermined location. I've tried saving to a local drive (c:\) and it works just perfectly. When I try saving to the networked wifi drive it breaks. Access says "The OutputTo action was canceled". I tried removing the filename reference from the code so that I can manually select the save location but it again breaks telling me "You cannot use an Internet address here. Enter a path that points to a location on your computer or on the network." This drive is networked over the LAN to the laptop. The computer assignes it a drive letter (Z:\) but apparently it still uses the ip address. I can access and browse the drive without any issue from "My Computer". Is there a way to make this work?

[elturbo3]

@zmbd

Dim filename As String 
filename = Me!txtLicense
DoCmd.OutputTo acOutputReport, , acFormatPDF, "y:InspectionResults\" & filename & ".pdf", False

Sorry, filename is a simple alpha numeric text string. Unless I'm missing something there aren't any slashes or other characters involved. It displays something like this "M12345".

The code "filename = Me!txtLicense" should simply be pulling the curent license number off my form and shoving it into the declared variable.

The code above works. I don't understand why but it does. InspectionResul ts is a folder on this networked wifi drive. Using the above code I get a file in that folder with the proper name. If I add the slash after the y: (y:\) it breaks.

[NeoPa]

There still seems to be some confusion, as you are still not presenting the information in a way that is helpful. We don't want to see a random example of what is sometimes found in that variable. We need to see the exact value, at the time it does or doesn't work in your post.

EG. From your post #5
This code doesn't work.

DoCmd.OutputTo acOutputReport, , acFormatPDF, "y:\" & filename & ".pdf", False

This code does work.

DoCmd.OutputTo acOutputReport, , acFormatPDF, "y:" & filename & ".pdf", False

The value of filename at the time was "XXXXX".

It may be that what you say is correct, but frankly we'd all be happier seeing the data rather than simply taking your word for it. I very much doubt you'd overlook something like that, but that's only an example of what we'd be looking for. Sometimes, you don't know the problem until you see it, and frankly, it just doesn't make any sense not to pass that information in a clear and simple way. Why complicate matters after all?

[elturbo3]

Well, I do not know how to show you exactly what is being processed. I did set a watch once in the code window and could see when the variable changed but no screen shot of that here, now.

The variable filename really has no bearing on the question. I can make it a static file name and i have the same issues. Refer to line 3 of the code I posted above. The save to path is "y:InspectionRe sults\filename. pdf". This code works. The only variable is filename. I can change it all I want, within the parameters of my program, and it sill works. "Y:" is the networked drive name, "InspectionResu lts" is the name of a folder. These things do not change, ever, unless I go into the code and change it manually. If I do go in and change it to "y:\" it does not work.

Also, if you remember in my very first post I told you that the code works just fine when saving to a local hard drive (c:\) so if the variable was adding an extra slash or causing something funny to happen then it also should have broken that code.

[NeoPa]

ElTurbo3:
The save to path is "y:InspectionRe sults\filename. pdf".

No. It isn't. Not even close. That would only ever be true if the contents of the variable [filename] were "filename". That's the difference between a string literal and a string (or compatible) variable.

Why can you not simply post the information as suggested (many times now) instead of trying to argue the point over and over again? Do you assume we are so stupid we cannot understand what you are saying? If nothing else it will get us off your back (which you may just have succeeded in doing anyway ironically enough). If you're not sure how to go about finding that information, wouldn't a sensible approach be to say so and ask how to do it? Rather than try to argue it isn't necessary?

The line to show the exact contents of that variable at the time that it runs, and either works or doesn't, is :

Debug.Print filename

ElTurbo3:
Also, if you remember in my very first post I told you that the code works just fine when saving to a local hard drive (c:\) so if the variable was adding an extra slash or causing something funny to happen then it also should have broken that code.

And if you remember from my last post I explained that, regardless of your assurances that you know what you're doing and it's not an issue, we would still like to see the data we're supposed to be helping you with. This is with good reason, as also explained in that last post, because we all have experience of being misled by members misunderstandin gs. This may well not be an issue with you, but how can we tell without seeing the data? How can we - X miles away from you - have any idea how reliable you are at explaining your situation when all the information that we do have is that you can't respond quickly and straightforward ly to a simple request. Let me tell you that is far from reassuring from our point of view.

If you'd simply done as asked (a number of times now), rather than try to explain to us that we are all mistaken even to ask for it, then we wouldn't all have wasted so much time.

Somehow, I doubt you'll be wasting any more of my time on this, at least without a sea-change in attitude.

[elturbo3]

@NeoPa
First I would like to say that I do appreciate the folks that volunteer their time on public forums such as this. I believe that you help many people every day and contribute greatly to the tech world.

You are correct in being suspicius of my knowledge and I don't blame you for that because I'm not a professional programer or an access consultant. I expect to make mistakes. I would thank you for showing me a couple of things that I didn't know like the debug line.

I don't want to be rude but I have attempted, probably badly, to show you in a logical fashion that the filename has absolutely no bearing on the problem. At the time of my last post I did not have access to the database to perform this test so I was attempting to again explain it logically. You will not accept this so here is the code and output of the variable.


This code works:

DoCmd.OutputTo acOutputReport, , acFormatPDF, "Z:InspectionResults\" & filename & ".pdf", False
 
Debug.Print filename
F14090
F4079
FL804
F8055
 

This code does not work:

DoCmd.OutputTo acOutputReport, , acFormatPDF, "Z:\InspectionResults\" & filename & ".pdf", False
 
Debug.Print filename
F8055
FL804
F14090
F4079
F40379
 

I then tried putting the entire path into the filename variable just to see how it would compile that way.

Works

filename = "z:InspectionResults\" & Me!txtLicense & ".pdf"
DoCmd.OutputTo acOutputReport, , acFormatPDF, filename, False
 
Debug.Print filename
z:InspectionResults\F6089.pdf
 

Does not work

filename = "z:\InspectionResults\" & Me!txtLicense & ".pdf"
DoCmd.OutputTo acOutputReport, , acFormatPDF, filename, False
 
Debug.Print filename
z:\InspectionResults\F6089.pdf
 

[zmbd]

About time!
I was about to unsubscribe from the thread.

If you had mentioned that you didn't have hands-on to the application we would have waited for the asked for information - instead you wasted my time. I try to fit these answers in during the 5 or 10 minute breaks between tests and other obligations. You'll find that I do not ask trivial questions - I don't have the time!


Your LAN wouldn't be on a UNIX server would it?

The other thought:
Naming Files, Paths, and Namespaces (Windows)

Fully Qualified vs. Relative Paths
For Windows API functions that manipulate files, file names can often be relative to the current directory, while some APIs require a fully qualified path. A file name is relative to the current directory if it does not begin with one of the following:

•A UNC name of any format, which always start with two backslash characters ("\\"). For more information, see the next section.
•A disk designator with a backslash, for example "C:\" or "d:\".
•A single backslash, for example, "\directory " or "\file.txt" . This is also referred to as an absolute path.
If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter. Note that the current directory may or may not be the root directory depending on what it was set to during the most recent "change directory" operation on that disk. Examples of this format are as follows:

•"C:tmp.tx t" refers to a file named "tmp.txt" in the current directory on drive C.
•"C:tempdir\tmp .txt" refers to a file in a subdirectory to the current directory on drive C.
A path is also said to be relative if it contains "double-dots"; that is, two periods together in one component of the path. This special specifier is used to denote the directory above the current directory, otherwise known as the "parent directory". Examples of this format are as follows:(...)

What does that mean... go change the current directory and it may break the reference and therefor your fix.

[elturbo3]

@zmbd
No, windows 7 laptop then I run a batch file that turns the wireless into a broadcasting access point. Then I can connect to that with other devices and it acts like a LAN.

[elturbo3]

@zmbd

I think you may be on the right track. I went to a command prompt and tried changing directories and found that I can type in z: and it will go there but z:\ give an error. Same thing happens with local drives. It's been a while since I used the dos command prompt but I don't remember it being that way. The drive name is z: but for some reason, maybe the webdav protocol or windows 7, it will not accept the z:\.

[zmbd]

It would be nice if I knew more about the internal workings of that protocol. Another expert will have to take over from here if we've truly hit that wall :(

[NeoPa]

@ElTurbo3. Post #15 does seem to reflect that sea-change of attitude that I was speaking of. Very nice to see.

ElTurbo3:
I would thank you for showing me a couple of things that I didn't know like the debug line.

You have only to ask generally. What we rarely know, is how much and what a particular member already knows and understands. If you tell us you don't understand something that can be of practical benefit, as we then know what can and cannot be said. Until then we must, of necessity, guess how best to pitch what we are saying.

ElTurbo3:
I don't want to be rude but I have attempted, probably badly, to show you in a logical fashion that the filename has absolutely no bearing on the problem. At the time of my last post I did not have access to the database to perform this test so I was attempting to again explain it logically. You will not accept this so here is the code and output of the variable.

I don't take any of this post as rude. I hope you appreciate now though, why I would not accept the information as you presented it. When something is as complicated already as this question is, it is even more important to do this absolutely, and positively, logically. Not allowing any possible loophole in the logic. The information we requested, and which you have now provided so well, is proving very helpful in that respect.

Of course, you original assertions, although not as reliable for us as the data they were made from, proved absolutely correct. Nevertheless, we would still insist on seeing what was requested. Believe me, if ever you get to be in a position where you are trying to deal with issues from the other side of a web page (and it's probably less unlikely than you might imagine at this point), you will appreciate the why of what we are saying (and do it the same way if you want to avoid easy mistakes).

ElTurbo3:
I went to a command prompt and tried changing directories and found that I can type in z: and it will go there but z:\ give an error.

This appears to be a mis-remembering of how the Command Prompt interface works. This behaviour is fully consistent with all versions going back to version 2 (I believe) of MS DOS. Z: is a command that changes the current drive to Z:. It won't change the current folder of that drive. Remember, The OS maintains an array of current folders. One for each lettered drive. It also has the concept of the current drive. Z:, when typed at the Command Prompt, simply changes the last of these. Z:\, on the other hand, is a reference to a folder but has never been a valid command. To change a folder you need something like :

CD "Z:\"

Even then, it simply changes the value for the specified drive rather than the current folder generally. To do that you need either of :

1. CD /D "Z:\"

2. CD "Z:\"
   Z:

This brings us on to the next question, which is what is the current folder for the Z: drive? The syntax that fails specifies the root folder explicitly, whereas the syntax that works uses the current folder on that drive. Whatever that current folder is, works, but we have no information of what that is so far (which is fair and reasonable as we hadn't previously requested that).

Please rerun the test for me on the version that works (a single test, or license number, will prove adequate for this.), but post back the info resulting from the following line of code :

X=Left(CurDir(),2):ChDrive "Z:":Debug.Print CurDir(), filename:ChDrive X