Hi Barb:

Thanx for the reply. You are correct, the cOp_Lname, etc. fields are only in the one table. What I didn't state, however, is that these are FP-2x free tables, and I found when I suspended and then messed with the cursor from the actual single name query (which does work okay) that DISPLAY STRUCTURE showed some calculated/defined output fields (not shown in my example) were marked as 'accept null = yes' -- but of course the native FP-2x fields did not (accept null=no). Your results showing .NULL. tend to point in that direction as the problem area, as well. If that is so, I suppose I'll need to do a "xxx as yyy" or some such on those fields to allow them to accept nulls. Not sure of the exact syntax needed on that, but I'll eventually figure it out...

Since I've got it running with my kludge work-around, I may not get to play with it again for a couple of days, but I'll report back if that fixed it.

Thanx.

Rob

>Hi Rob,
>
>I tried a similar SQL, and had no problem. The only thing I can think of is that somewhere your SQL is having trouble with the NULL values that result when there's no record in Permissions. Mine showed '.NULL' in the fields for the 'right side table' correctly.
>
>I'm assuming that your cOp_Lname and cOp_Fname are only in one table? If there are duplicate field names, this could be causing a problem as well.
>
>Barbara
>
>>Hi All:
>>
>>Trying to get someone else's code to run and having a problem during testing that needs resolution before placing this into production.
>>
>>I have two tables -- operators and operator permissions. The idea is to print a report with all permissions for each operator on it. There is a filter dialog where one can enter a specific operator's name and it will just print for that one, or if blank it will print for all operators in the operator table. The earlier programmer made a SQL select to combine the info from the two tables, something like this (simplified -- many more fields included in the actual code):
>>
>>
>> SELECT DISTINCT ;
>> Op_Info.cOp_ID, ;
>> cOp_Lname, ;
>> cOp_Fname, ;
>> FROM Op_Info ;
>> LEFT OUTER JOIN Op_Modul ;
>> ON Op_Info.cOp_ID = Op_Modul.cOp_ID ;
>> WHERE .T. ;
>> INTO CURSOR OperTemp1 NOFILTER
>>
>>The "WHERE .T." is the evaluated where clause if all operators are desired, otherwise it is something like 'WHERE operator id = "xxxx"'...
>>
>>Problem is: If I choose a specific existing operator, it works fine, but if I have operators that do not currently have any access rights, (ie: operators that do not exist in the permissions table) the SQL fails with 'datatype mismatch'.
>>
>>I isolated the problem to the LEFT OUTER JOIN clause. Before that point, the sql works fine. As soon as I try to add in the LEFT OUTER JOIN clause it fails if I have any operators without at least one record in the permissions table.
>>
>>When I tracked down the problem, I kludged together a quick fix to just scan the permissions table an put in a dummy record if a given operator is not found, but I really want to do this right -- and I really don't understand the LEFT OUTER JOIN problem.
>>
>>Any help would be appreciated.
>>
>>TIA
>>
>>Rob