FilePut extremely slow on network drives

[pbishop]

We use FilePut to write some binary files. When writing these files to the users local C drive they write in a few seconds. We have users wanting to store these binary files on their network drives. When going to a network drive they are taking 4 minutes or longer to write. What would cause FilePut to write this slow going to a network drive but a few seconds to do the same write to a local hard drive. Here is an example of the code.

FileOpen(ZZDBFileNum, SPN & "._ZZ", OpenMode.Binary, OpenAccess.Write)
FilePut(ZZFileNum, PAID)
maybe 80 more of very similar file puts above.
FileClose(ZZFileNum)

The file above again would take a few seconds to a local drive and 4 minutes or longer to a network drive. The file it's writing is only 2.5mb in this case.

[dday9]

I am curious, what happens to performance if you run the .NET equivalent?

' Imports System.IO

Dim filePath = $"{SPN}._ZZ")
Using fs = New FileStream(filePath, FileMode.Create, FileAccess.Write)
    Using bw = New BinaryWriter(fs)
        bw.Write(PAID)

        ' other write commands here

        bw.Close()
    End Using

    fs.Close()
End Using

If you do not get a significant performance boost, I'm wondering if it is just network latency in which case I don't think that there's much you can do.

[OptionBase1]

We use FilePut to write some binary files. When writing these files to the users local C drive they write in a few seconds. We have users wanting to store these binary files on their network drives. When going to a network drive they are taking 4 minutes or longer to write. What would cause FilePut to write this slow going to a network drive but a few seconds to do the same write to a local hard drive.

The first thing to do in cases like this is remove all coding completely from the equation. How long does it take to simply copy/paste a file of roughly equivalent size via Windows Explorer to the same network location that the code is copying it to? If that takes a while as well, then the network appears to be the pinch point, so approaching this from a standpoint of making the code work faster would be a fool's errand.

Edit to add: Long ago, I worked at an institution where there was this weird bug where if both our Compaq servers and the Cisco switch ports that they were plugged in to were both set to auto-negotiate speed, the server would pick 100/Half duplex, and the switch port would pick 100/Full duplex. The result was crazy slow network traffic to the server. It "worked", but it was maddeningly slow. Could be something like that in play here.

[pbishop]

takes seconds to copy as well to that network location

[dday9]

takes seconds to copy as well to that network location

And if you try the .NET code?

[TysonLPrice]

takes seconds to copy as well to that network location

I don't know what your environment is but at that point I would get the network people to trace it.

[pbishop]

And if you try the .NET code?

Hopefully will try that today.

[Shaggy Hiker]

As you may have guessed, there is nothing obvious that should be causing this. If there was some known issue, you'd have an answer. Therefore, the solution to this is going to involve a certain amount of experimenting. After all, there is one odd work around that comes to mind: Never write to a network drive. Instead, capture where the user wants to write to, then write to a temp folder on the C drive and copy the file to the destination. That would be a horrible hack, but it sounds like it would work. Testing the .NET solution would also be a good thing to do, though if that does work then it is likely that you will never fully understand what is going on with the Put.

[jdc2000]

What antimalware software is in use on the target system? That might be a potential cause.