It sounds like the issue is computer-dependent, not user account-dependent. Is it limited to a single workstation, or more than one?

>Thanks for the input. It's clear I'm gonna have to dig deeper into this.
>
>I should clarify that this whole business with SQLSTRINGCONNECT() was sort of a sidetrack. The original problem I was getting is that when trying to open a remote view to the table, I was getting an error that seemed to indicate that the table was not accessible or present (I don't recall the exact message right now). I was only using SQLSTRINGCONNECT() to check to see if the problem was with opening the connection to SQL Server, or the database. I was basically getting the same error when the SQLEXEC() was used to query the table contents.
>As stated earlier, the head-scratcher was that I was getting an error with one user but not another. Both users were members of the same group, the group was assigned the db_datareader, db_datawriter, and db_owner roles (and as far as I recall, I don't recall seeing a situation where any of there were any groups or users assigned the roles of db_denyread or db_denywrite roles). The strange part came about is when the user that was experiencing the problem logs into a different workstation, the problem goes away.
>
>>Hi Naoto,
>>
>>This feels like the sort of temporary error state sometimes seen with asynchronous or shared connections... except that SQLConnect is not shared, ASYNCHRONOUS false and BATCHMODE true. So SQLEXEC should never return 0 (still executing)... but if it did, this code will call that an error. Perhaps isolate SQLEXEC's 0 return separately, in case that's somehow the cause:
>>
>>

    nRet = SQLEXEC(m.hConn,"SELECT * FROM dbo.SYSCONF","RV_Sysconf")
>>if m.nRet=0
>>    Error "Database asynchronous SQLEXEC should not have occurred"
>>Else
>>    IF nRet < 0 THEN
>>      local laError(1)
>>       aerror(laError)
>>       Error Transform(laError(1,1))+": "+laError(1,2)+NVL(": "+laError(1,3),"")
>>    ELSE
>>        *
>>        * some other stuff happens here.
>>        *
>>        USE IN (SELECT("RV_SysConf"))
>>    ENDIF
>>endif

>>
>>Also I'd recommend using AERROR() to try to refine any ODBC error return... elements 4, 5 and 6 could give you an "aha" moment.