I'm not an expert for SCX/DATENVIRONMENT, I use forms via VCX and add my DE's at runtime, and do all datahandling by CursorAdapter, skipping all this inner workings. It was to ugly to maintain.

So you have
- a form with a DE
- the DE holds one cursor object for your table

This table is open and holds all the records you expect, right?

And then you run a VIEW against that table, or is this a different object in your dataenvironment?
And this does not show the number of records you expect?

Is this the setting?

Otherwise it might be better to have the code (the scx and an example of the data), it becomes to complex to understand, and we loose information an the translation.

>It was my error. Weird thing though. Perhaps you'll be able to explain to me the inner working of VFP, or anybody else for that matter.
>
>In the data environment of the form that I use to add the data needed for that particular report, I had a table in the data enviroment. A table that will contain the data needed for my report.
>
>So I can understand that it could cause a problem. The thing I don't understand though is why only 3 records our of 4 were visible for my report.
>
>Thank you very much for your feedback. Always good clues to help me.
>
>Regards,
>Denis
>
>>Look, a view is nothing then a way to run a SQL SELECT against other cursors (temporary or permanent cursor aka table) create a new cursor and apply some some stored settings to this cursors "properties".
>>
>>Running the VIEW DEFINITION, i.o.w. the yQL SELECT command, NOT THE VIEW enables you to play with the expressions in WHERE and ON. I'm not sure if there is a direct command to return the view definition, in case browse the DBC via use.
>>
>>So if you have your tables open, browse all of them that are used in the view, and run the WHERE / ON expressions (debugger?) against any pair that you expect to be included in the result cursor.
>>first run the ONs
>>second run the WHERE
>>(SELECT SQL will create an intermediate result based on JOIN / ON and limits this result later by WHERE (...))
>>If you have multiple ons, run then in single steps, check the order they are running.
>>
>>Ah, and one trick
>>If you use tables, check if you index is not corrupted. Rushmore compares indexes, and if the index is corrupted, the return is useless. There is as SYS that you can use to return the rushmore stuff
>>
>>>>You say the report shows only 3 records. I assume you mean the cursor of the view holds 3 records?.
>>>>What is reccount("NameOfMyView"), _TALLY after requery, how many records are visible with a browse?
>>>
>>>Yes cursor of the view. I did a browse,. 3 records
>>>
>>>>A view is an odd way to store SQL selects. So we talk about the SQL SELECT.
>>>>Get the view definition and run from command line or a Modi Comm window.
>>>
>>>All the data in the tables were created. so executing from command window after quitting the app will show me all records.
>>>
>>>>
>>>>The basic stuff limiting the return of a SQL SELECT:
>>>>Value of SET('DELETED')?
>>>>Is the view using DISTINCT, GROUP BY (HAVING) or UNION?
>>>
>>>No
>>>
>>>>Are there WHERE or ON clauses?
>>>
>>>Yes
>>>
>>>>JOIN set to the wrong side?
>>>
>>>No
>>>
>>>>Else you need to check your frx. Use a copy of the existing frx and remove item by item. If it will not help, recreate the frx step by step while running it after each step. EACH.
>>>
>>>FRX shouldn't be the problem because if I quit the app and get back the browse show me all records. and reports also show 4 records.
>>>