>It's rather straightforward:
>
>Somehow, the first method didn't produce errors and the second does. The errors occur on the server when remote workstations log in. Local machines seem to be able to run either command without problems.
>
>

>oApp.gnHandle = sqlstringconnect(oApp.gcConnStr,.t.)     && in the main program
>
>and
>
>Use  myview again in 0 alias myview nodata connstring oApp.gcConnStr shared      && in DE.OpenTables()
>
>or
>
>Use  myview again in 0 alias myview nodata connstring oApp.gnHandle shared        && in DE.OpenTables()
>
>

>
>Of course there are multiple views and multiple forms so there could be upwards of 50 processes sharing one handle. In a worst case scenario, it would appear that using the handle can down the server. I can't believe what they are reporting but I'm 1500 miles away so can't observe this directly. I'm guessing (hoping?) that the problem will be found elsewhere...

Actually in VFP Help on USE command one can see a confusing phrase:
"Visual FoxPro supports overriding the default connection for a remote view and requires the nStatementHandle parameter for supporting shared connections. ", from which it may be derived that only nStatementHandle parameter should be used for remote views.

But as far as I know, both options are valid,
.... CONNSTRING cConnectionString
.... CONNSTRING nStatementHandle

The difference is (as seen in VFP Help): "When you use cConnectionString, Visual FoxPro passes the connection string to the remote view that you specify with SQLViewName, which then uses the connection string to connect to the specified data source instead of using any previously defined connection string."

So, in theory it does not matter what parameter are you using.
Sharing one handle, I do not think it is the problem either.

Are you sure that you close connection properly? Is there a limit on the number of connections on the server? Does behavior depend on the number of users working simultaniously with application?