Code suddenly stopped working..... (1 Viewer)

I have been running this code in production for over 2 years now, works like a charm until today in my development environment,

sFName = "s:\sql-ledger\SOWO-Export.csv"
iFNumber = FreeFile
Open sFName For Output As #iFNumber

I did check, drive S: is definately there, the directory \sql-ledger\ is there. I even went so far as to delete the old CSV file. Nothing helped keep getting an 'error 76 path not found' on the open command.

Anyone have an idea why my development environment went nuts in the last few weeks?:banghead:

It would be better if you posted the complete code, including variable declarations...

After some security updates, you might get permissions violations. Can you manually drop a file in that folder? (Doesn't matter what kind of file.)

Also, does the trap give you the option to debug the code? Because if it does, I would immediately check what is in variable sFName. Open the Immediate Window and use the Debug.Print command to see what is in the variable.

I would expect a different error if the problem was in the FreeFile return, but if you are checking the sFName variable, check the iFNumber variable while you are at it.

Looks like that is the issue, a security issue. How do I tell Access to write to drive S: like always. Drive S: is a Samba share on a Linux server. This drive can not be changed, as this is where another program is looking for the file once it is created.

Any ideas how to fix this annoying problem

Can you copy the file to a read/write folder somewhere else? If so you could do this in your procedure.

I am outputiing to a text file. I did try writing to C:\ And that worked perfectly. guess i could create the file on C: then move it later.... not ideal but would work.

And yes my id has full control over the entire S: drive.

Process of elimination: Your program can write to the C drive. So it's not your code that is at fault.

You didn't come out and say it, but your comments in post #4 suggest that an attempt at a direct copy from the Windows GUI must have worked. So it isn't a traditional security issue, either.

If your user ID has Full Control permissions on S: and you are not doing a "Run As" (implying that Access is running as YOU, not as someone else like SYSTEM), that means it isn't a permissions issue on the S: drive. Full Control is Full Control; there are no "flavors" of that level of permissions.

Network security permissions (on the share folder) are separate from the Full Control set that you mentioned, They could equally prevent writing from the Windows GUI and from MSACCESS. But the GUI works. So it isn't likely to be NETWORK permissions on the folder either.

What is significant to me is that you can copy to the folder but can't directly create the file from Access. This might be a NETWORK FIREWALL security issue. File copying via the Windows Explorer GUI uses SMB to get to other shared folders on other systems regardless of which O/S is in play. So it isn't a general SMB protocol block. If it really IS what I begin to think it is, the file copy would ALSO fail if performed by Access because the SMB protocol isn't the problem; it is the program doing the sending.

Your problem APPEARS at first glance to be using SMB from something OTHER THAN Windows Explorer to write to a share on another server for which you have Windows Full Control over the share.

You need to talk to your site's security administrator and ask if they have put a block on SMB traffic from specific applications (such as MSACCESS.EXE). This would be at either a segment "smart" router or segment firewall that leads to that server from the network segment where your machines are located. It has to be something that is context sensitive, so a "normal" router wouldn't do this.

I had the same problem getting to one of our site's SMTP Gateway systems because it blocked programmatic transmission. Since I was using Access and the CDO library to get to that server, I got blocked. We had to get an exception posted in the smart router for that system and MSACCESS.EXE so that we wouldn't get blocked.

Sorry to take so long to get back, I had to do a bunch of restores of my test data....
I miss spoke, where I could move the file from drive D: to drive S: through Explorer, then VBA issued the command:
FileCopy "d:\SQL-Ledger\SOWO-Export.csv", "s:\SQL-Ledger\SOWO-Export.csv"

The program crashed again with the same error as before, about path not found.

If that crash was a FileCopy triggered through MSACCESS.EXE via VBA, that is consistent with my earlier analysis. That file operation would ALSO register on smart firewalls as an MSACCESS.EXE operation rather than an IEXPLORE.EXE or WEXPLORE.EXE or whatever MS calls Windows Explorer on your version of Windows.

Let's be explicit. Can you manually copy that file to your S drive by using the Windows Explorer GUI to do so? Simple drag-n-drop copy, no frills, no fancy stuff. Can you do that copy operation by hand?

If yes, re-read my prior long analysis and talk to your security folks.

If no, then something a lot more bizarre is going on and will require some thought.