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?

[NeoPa]

Although this presents in Access, I believe it's actually a problem related to the O/S. I'll move it there in case anyone there has further insight into why this may be happening and what could be attempted to get around it. It may be possible in Access to get around it by using other export approaches, but that's a different question.

I suggest you first test that you have full access to the folder you intend to export to.

If you find you do then you could try setting up a new drive letter to point to that same drive (or even folder) using the old DOS command SUBST. SUBST /? from a command line will give you the full syntax.

[zmbd]

As Neopa has said, find out if you have read/write/modify rights to the destination.

If so, then if the Admin mapped the drive using the IP address you may not be able to work around this; however, if you can get the UNC for the drive then you may be able to get there: How to Return a Universal Naming Convention (UNC) Path from an Existing Drive Letter I know it's for MSA 2000; however, it works in my current DB under 2010.

[elturbo3]

I can certainly save and delete files from this wifi drive while it is networked to my laptop. I'm afraid this is a limitation of Access or the OutputTo method in general. The UNC is in the form \\IP Address\DavWWWR oot. This method does not like IP address.

[elturbo3]

Bah...

Figured it out! I've tried this a million ways with IP address and drive names but it was ultimately a syntax issue with the drive name I guess. Well, thanks for the suggestions guys. Appreciate the help!


This code doesn't work.

DoCmd.OutputTo acOutputReport, , acFormatPDF, "[B]y:\[/B]" & filename & ".pdf", False

This code does work.

DoCmd.OutputTo acOutputReport, , acFormatPDF, "[B]y:[/B]" & filename & ".pdf", False

[zmbd]

It would have been helpfull to have posted the resolved string. I suspect that "filename" variable may already have a leading backslash.

[elturbo3]

It would have been helpfull to have posted the resolved string. I suspect that "filename" variable may already have a leading backslash.

filename=Me!txtLicense

This also works to get to a folder on the networked drive.

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

[zmbd]

Close... but no cigar...

filename=Me!txtLicense

But what is the actual string... what does id resolve to I suspect something like "\thepathtothef ile\filetopen"

[NeoPa]

What Z is saying, with reference to your post #5, is to post the exact value of the contents of filename when you post what does and doesn't work, otherwise we are still in the dark as to what you are actually asking Access to do for you. As he says, it may be that the contents of that item are formatted in such a way as to cause a problem in that particular context. Only by seeing that can we analyse what you're telling us and, hopefully, explain it for you.

[Rabbit]

Basically, if I tell you

y = x + 2

And when I look at y, and it's 7, but I'm expecting y to be 4, and I ask you why y isn't 4, you would ask me to look at what's in x.

And if I was to inspect x, I would find that x is equal to 5. And so I would have to find out where I set x and why it was set incorrectly.

So if you ask me what the value of x is, I should respond with x is 5. The response would not be x is y = x + 2.

[elturbo3]

Close... but no cigar...

filename=Me!txtLicense

But what is the actual string... what does id resolve to I suspect something like "\thepathtothef ile\filetopen"

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]

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

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.

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