That's a great idea, but would kinda require watching it until a dropped
packet is spotted with another command prompt window open ready to tracert
just by hitting enter I guess... I don't have that kind of time, I'm still
pulling the last source data into the database from the legacy system now
that my update routine is all debugged.  (I'm not supposed to be an
admin!!!)

>> The script has been running from my desktop and another
>> desktop which I think takes the same route to the server,
>> that eliminated my desktop as the problem.   And then
>> yesterday I also started it from my desktop to
>> my other SQL Server server (which is on the same VLAN as this
>> one so I guess that's again the same route but if that one
>> doesn't have the problem then we would know it's this one,
>> right?), but running it double on my desktop apparently
>> doesn't leave any spare CPU cycles for pcAW, I can't connect
>> now.
> if you haven't done it yet, have you tried a traceroute (tracerte in some win
> os')?? that should, if the routers are advertising their addresses, tell you
>the route that your traffic is taking... if you can get a traceroute run durin
>a failure, that'll tell you either the last good hop or the failing one in mos
> cases...
> )\/(ark

--- BBBS/NT v4.01 Flag-5