Hi Ronald,

this is typically a function of the domain server having to authenticate the server you are on. When it does so, it hands of a domain cookie to the server, which can be used for subsequent connections. If you were to maintain a share, but used the UNC (which is definitely the safest way to go, because shares can come and go unless they are in your startup script), you should find that the delay is gone.

Another thing to look a, related to the firstt: when you created the mappings, you likely did this from an admin account. But the user is running, probably, from a user account. If you were to run the application as an admin user, you might find that the UNC connection times perk right up.

In any case: if the network/user permissions are set up right, UNC is not slower than a mapped drive.

hth,

Hank

>After moving to a new server installation, we have been having "delayed write errors" off an on. Seems to be when we have heavy usage. Before the switch, all workstations had a mapped drive to the database location on the server. After the move to the new server all workstations located the database location using UNC.
>
>Our guess is that with the UNC naming convention, there is a delay in opening the Databases for usage and when heavy usage, this would be causing a problem and throwing the "delayed write error". We changed the datalocation to mapped drives and it seems to have solved the problem.
>
>The number of workstations are not that great. Approx. 25
>
>I an not comfortable that this is really solving our issue, however, it seems to have corrected the problem with mappings.
>
>Has anyone experienced problems like this?
>
>Thanks in advance