Why can NET USE fail sometimes when run from dBase?

[dbMark]

Here's an unusual failure I've encountered. From within a dBase program I run the NET USE command to establish a connection to another user's shared printer, suppressing messages reporting success to avoid unnecessary screen clutter and user response. Very rarely it fails. In this case no failure was reported yet the printer connection was not made even after a second try. But when I ran a DOS batch file from within dBase the printer connection succeeded. The question, what made the difference between a direct call to NET USE versus the batch file calling NET USE? Both were RUN from the dBase environment.

No doubt this has something to do with the inherent lack of synchronization or full compatibility between the DOS world and the various versions of Windows but I haven't nailed down the exact culprit yet...

Looking back, I must admit that I didn't first reboot both computers, the one hosting the printer and the one making the connection. That's my rule #1. But I'm not sure that would have made a difference.

This problem first appeared a couple months ago in a Windows Millennium workstation, then later on an XP workstation connected through gigabit switches to a fairly new Windows 2000 SP4 file server. Yesterday it surfaced on a WinMe workstation again. Each printers is connected locally to various workstations throughout the offices and the printer drivers are installed as usual in the host computer's Windows environment and the share name is always "printer" for uniformity.

PROCEDURE pr_link
PARAMETERS p_cpu
*  Note if p_cpu="DELETE" or undefined/empty then release LPT2
PRIVATE c_cmd, l_fail, c_dest, n_hand, c_data
l_fail=.F.
* Windows 2000/XP require deletion of prior NET USE connection
c_dest="C:\WINDOWS\TEMP\_NUL.TMP"
IF FILE(c_dest)
   ERASE (c_dest)
ENDIF
c_cmd = "NET USE LPT2 /DELETE > "+c_dest
! &c_cmd
* Me fail message: "Error 3: ..."
* XP fail message: "The network connection could not be found. ..."
IF TYPE(&quot;p_cpu&quot;)=&quot;C&quot; .AND. p_cpu<>&quot;&quot; .AND. UPPER(p_cpu)<>&quot;DELETE&quot;
   IF FILE(c_dest)
      ERASE (c_dest)
   ENDIF
   c_cmd=&quot;NET USE LPT2 \\CPU-&quot;+p_cpu+&quot;\PRINTER > &quot;+c_dest
   ! &c_cmd
   IF FILE(c_dest)
      n_hand=FOPEN(c_dest)
      IF n_hand>0
         c_data=FREAD(n_hand,254)  && dBase string limit
         n_hand=FCLOSE(n_hand)
         IF &quot;Error&quot; $ c_data .OR. ;
             .NOT. &quot;completed successfully.&quot; $ c_data
            c_data=STRTRAN(c_data,CHR(13))
            c_data=STRTRAN(c_data,CHR(10))
            IF LEN(c_data)>0
               l_fail=.T.
               WAIT c_data  && display failure message
            ENDIF
         ENDIF
      ENDIF
      ERASE (c_dest)
   ENDIF
ENDIF
pr_done= .NOT. l_fail
pr_fail=l_fail
* pr_done/pr_fail are external variables holding results
* but if this procedure is converted to a function
* then a value could be returned on the RETURN line
RETURN

* Note that this procedure uses a function STRTRAN() not found in early dBase versions such as my version 5. I have a copy of its code in my Emulated FoxPro Functions FAQ faq290-3518.

 

[dbMark]

This time it happened to me during my testing and I found the cause to be program code not the tempermental Windows environments! Turns out the program in question included these two lines which we use only on rare situations when we want to search using partial information or when the index contains several fields but we are only searching the first one or two.

SET NEAR ON
SET EXACT OFF

The culprit was SET EXACT OFF which started the above code with some unexpected status. I have added detection and now I hope the problem disappears...