now if this does not fly ... investigate the following ...
- how are you creating you VPN trusted connection / what software are you
using?
- how are users athenicated on the VPN?
- when the user can not connect to the database, can the 'SEE' the sql
server machine - ping it, map a shared folder, anything?
if user can see it ...
- what type of authenication does your vb application use to connect ...
secure or username password?
- Does the user security credential expire???
if user cannot see the machine ...
- can the user see other machines on the VPN?
....and so on....
there are too many unkowns for ANYBODY to give a solution. This should be
an easy problem to fix ... you just need to isolate and find the problem,
before you can ask for advice.... OTherwise, we can only tell you what to
check ...
The VPN connection is the first place I would investigate ... it can not be
the software, you are not having to re-install the database and rebuild the
dataset...other users at not impacted when a site goes 'off-line'...
I think it is a communication problem ... We have 14 offices all
interconnected with Cisco hardware and Cisco VPN clients (for remote users).
We have about 25 applications that use a common MSSQL database server
'farm' - 5 servers, each hosting 5 applications. When users 'lose' database
connection and their programs no longer work, it is mostly due to their
machine not being authenicated on the network and the server blocking its
access. SOmetimes a machine will use cached network security creditials,
giving them temporary access. BUt once this runs out, they will lose
connection to the database ... they can ping it, they can see it, but
regardless of the connection method, MSSQL will not allow the machine to
connect unless it has the proper security creditentials from the DSN Server.
If you are reinstalling the OS .... you are not solving the problem ... you
are avoiding issue. and, to avoid downtime, please see previous post.
Jeff.
- when it fails, can the user connection to the VPN
"jeff" <jhersey at allnorth dottt comwrote in message
news:OR**************@TK2MSFTNGP02.phx.gbl...
here is your solution ...
Low risk ...
n = number of sites that connect remotely ...
- go purchase n + 1 new machines.
- install your software on all the machines.
- ship a new machine to each site.
- tell them to only use it once they are infected and can not operate.
- as machines go off-line and do not work ... introduce these new machines
- bad machines are sent back to you, so you can re-install the os and
software.
- send machine back to user.
this will fix you problem but it is not a solution!
Higher risk ...
Same as above, but only purchase n * .25 computers and keep them on hand
and ship them out to impacted sites ASAP.
Either of these approaches should fix your problem and should reduce the
downtime due to your problem.
Thanks
Jeff
"Toni" <ne**@maila.hrwrote in message
news:f0**********@magcargo.vodatel.hr...
>>Did you really need to send this to so many groups?
I am in trouble. My bosses want's that I fix this problem immediately,
but I don't know how. Please help!!!