>I've found in the past that adding SQL Srvr terms such as (NOLOCK) or even such as (NOEXPAND, etc) ~ which would all seem very logical and useful under related circumstances ~ actually produces an error within the context of the ODBC string. I wish that it did work.
>

Hmm, I haven't had any problems using NOLOCK hints. Are you using connection strings to connect or a DSN? Not that it should make any difference....
Now, you may not be able to store this in a view designed/modified using the View Designer (since the designer may choke on it), but a coded view or an SPT command string should be fine.

>That leaves me wondering why some of my queries via ODBC either using a remote view or SQL pass-thro place 'shared' locks and others place 'exclusive' locks. There must be an explanation for this variance in behaviour but it is a mystery to me. Thnx again for the idea. /psb

SQL Server is the lock handler here. It all depends on what kind of lock SQL Server determines that it needs (table, extent, page, row, etc.) to do it's job. It's possible that today it might use a page lock and tomorrow escalate to a table lock, depending on how the data has changed.