My first impression is no. Since BEGBAL would be a numeric value, there would be no way to define the size of the value unless you defined it with something like BEGBAL = 99999.99, but that would give the wrong value. It would be better to have something like:

Select ;
00000.00 as begbal, ;
etc....

which would allow for number up to 99,999.99. If you need larger values, just use more zeros.

You also have what appears to be 0.00 as logamt. Consider this value as well in the same way.

You see, the first record in each SELECT output cursor defines the field types and sizes for that cursor. So if you have a 6 digit, 2 decimal numeric field as the first field in the first select statement, it must also be a 6 digit, 2 decimal numeric field in the first record of the second select output cursor. Otherwise, there is a mismatch. There would be a similar concern for character fields in the first records if you had character fields. Consequently, the first record also defines the size and type of the field for all subsequent records in the select. If you are just referencing existing fields in a table, this is generally not a concern since the table definition prevails. However, when you have a calculated value (or a default fixed value), it is something you have handle manually.

(I'll be off-line until tomorrow morning. Anyone else is welcome to jump in in the meantime.)

Mike


>Mike,
>
>If I declare the BEGBAL variable before hand with a LOCAL call, would that help correct this problem?
>
>Thanks
>
>>To start, please clarify the first select which appears to have a few parenthesis missing.
>>
>>But in general, you define some default values as 0.00. If these happen to occur in the first record, they define the size of the field, in other words a 4 character number with 2 decimal places. If other data in other select statement has a different value for its first record that is not 4 characters with 2 decimal places, you will get a union incompatible error. In other words the field definitions must be exactly the same. You can specify zero values as 00000.00 for example just to 'define' the field size.
>>
>>HTH
>>
>>Mike
>>
>>>Well,
>>>
>>>I HAD a complex SELECT with a UNION but it gave me an error - I performed a HACKUP job on my SELECT statements and got down to these 2 fields in each select. Can
>>> someone tell me WHY I am still getting a UNION incompatible error? What am I doing wrong!!!!!
>>>
>>> Thanks
>>>
>>>
>>> Select ;
>>> sum(iif(code.codetype="Time" and log.logdate iif((code.codetype="Expense" or code.codetype="WIP")
>>> and ;
>>> log.logdate iif(code.codetype=="Billings" and ;
>>> log.logdate 0.00 as logamt ;
>>> from Timepro!log left join timepro!code on log.codeid=code.codeid ;
>>> where log.firmid=gFirmid and log.logdate<=gEnddate and log.clientid<>0 ;
>>> UNION ALL ;
>>> Select ;
>>> 0.00 as begbal, ;
>>> iif(code.codetype="Time" or code.codetype="Administrative",log.time*log.rate, ;
>>> iif (code.codetype=="Billings",log.rate*-1,log.rate)) as logamt ;
>>> from timepro!log left join timepro!code on log.codeid=code.codeid ;
>>> where (log.firmid=gFirmid and log.clientid<>0 and ;
>>> log.logdate>=gStartDate and log.logdate<=gEnddate) ;
>>> into cursor curswip ;
>>> order by 1 && clientid & codenum