I don't know about "advanced" server.
I was involved in a recent switch from Novell 5 server 400MHz to a Win2000server 2.4GHz. Wow, lightning fast. The old server was suffering weird data corruption issues towards the end so that rushed the change. I blame 1/3 older hardware being used by more users, 1/3 Novell known thrashing issues, and 1/3 Microsoft and their brilliant ways to mess up Novell connections just enough for users to give up in frustration.
Anyway, we had to stop using queues and used the NET USE command (by the way the 9x/Me version appears to behave slightly different from the NT/2000/XP version, surprise!) which prints faster. We reserve LPT1 for the local printer and use LPT2 for connecting to another workstation's printer. That way we don't get into accidental forever-loops in case 2 users link to each other.
To set:
NET USE LPT2 \\username\printersharename /YES
To clear:
NET USE LPT2 /DELETE /YES > NULL
(note: Win2000 may not dump/redirect the message as expected?)
Within the program we keep a few variables listing the currently selected user we're connected to (in case we want to programmatically change to another printer and then reset back to where it was before) and the port (either "LPT2" for a remote printer or "" for the local printer).
pr_port="LPT2"
username="SAMUEL" && perhaps selected from a list
! NET USE &pr_port \\&username.\printer
* If NET USE displays a message, dBase says "Press any key"
* you could redirect output to NULL and instead
* test DOS errorlevel with a .BAT file?
SET PRINTER TO &pr_port
SET PRINTER ON
USE prtdbf
REPORT FORM rptname TO PRINT
SET PRINTER OFF
SET PRINTER TO && PAUSE/STOP REDIRECTION
! NET USE &pr_port /DELETE /YES
We have not encountered any problems with record locking, but are starting to get LOTS of "Too many files open" errors which we never got before. Haven't determined the real cause yet, but other posts indicate we are now printing faster than dBase 5 can handle, or don't have a larger FILES=nn count in CONFIG.SYS (Hmmm, WinMe does not have that file!) or maybe we are QUITing without first first closing all tables and returning to the master program. Take your pick...
Also, be forewarned that a Windows2000server is not as helpful as Novell was. Novell populated the computer environment so that dBase command ID() returned the user's login name. MS doesn't and so the ID() function returns only the workstation's name! (Visual FoxPro return both the workstation name and the login name combined.) So we may eventually add login/password directly into the dBase programs in case users moves between workstations.