[AccessD] OT: TS and Automation

Drew Wutka DWUTKA at marlow.com
Thu Jun 26 11:41:24 CDT 2003


Where was the printer running from, was it on a print server.  There is a
known print server bug between NT 4.0 print servers and Windows 2000
machines.  It causes a massive amount of connections, which exceeds NT 4.0's
limit.....which doesn't really show up as memory or CPU resources, however,
it completely blocks access to the print server (so if it is also a PDC or
BDC, you just locked a lot of people out of the network)

Drew

-----Original Message-----
From: Henry Simpson [mailto:hsimpson88 at hotmail.com]
Sent: Thursday, June 26, 2003 11:24 AM
To: accessd at databaseadvisors.com
Subject: [AccessD] OT: TS and Automation


Yesterday some users ran some automation code that creates Word instances in

a loop and kills them after printing but it turns out that the printer was 
so slow that the number or Word instances increased to the point that the NT

Terminal Server ran out of some kinds of resources and started giving 
spurious error messages about not finding a printer, being unable to install

a printer and then User32.dll errors and path not found errors.  One user 
was eventually unable to open any applications except that which was already

open.  An admin cleared the excess Word instances, as many as 18 that outran

the printer, and then the user was able to work for a while.  Ultimately, 
afflicted users logged right out and back in again as a precaution.

After that, more and more users began to have problems and ultimately, no 
one was able to log in to the server.  Before it all completely failed, an 
admin took a look at resource and there was plenty of memory and low 
processor usage and all unnecessary instances of applications were cleared 
yet every single person started getting the user32.dll error and, after 
logging out, was unable to log back in due to a time out even though the 
Terminal Server was on a local LAN.  The admin was able to see that all 
users were out and no user applications were running but he also got a 
user32.dll error from which there was no recovery.  An attempt to restart 
from Task Manager gave the same user32.dll errors and after 45 minutes of 
recovery attempts, it was finally decided to interrupt the power off the 
server.

Ultimately Access automation code took full responsibility for the fiasco 
and the Terminal Server was blameless.

I'm not desperate for solutions as code can revert to a single Word instance

- multi Document with 20 second time delay approach that worked in the past.

  I could use help with code that pauses the Access automation while it 
waits for a print job to complete.  So far I've dabbled with

          objWord.Options.PrintBackground = False
          objDoc.PrintOut Background:=False


What gets me is the Admin view that the Access code is responsible for their

inability to release resources that were some how used but didn't show up in

any resource monitors or error logging.

Hen

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.  
http://join.msn.com/?page=features/junkmail

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


More information about the AccessD mailing list