OK then....
>> I thought we understood each other
That's why I'd made the comment earlier on. Assuming understanding is the mother of all..., well... it's not good.
>> I didn't mention anything about entering same values, otherwise I would explicitly tell you that.
Again, that's a one-sided assumption. Because you didn't mention that the values were the same, you assumed I accepted that they were different.
It could be argued because you didn't assert that they were different, that I assumed they weren't different. See my point?
I, on the other hand, asked the question - and I did so because this is fundamentally how RecordSources work. They do not relate to what is displayed on a form (that's a form's Recordset). They are a description of what WILL be shown on a form when its opening request is made.
>> And I know It can be done, actually It works when you add these lines before opening report:
Again, that's throwing ideas at the problem hoping something will stick.
It's much more important to understand what is going on and how data requests work.
I'll explain what that "solution" is actually doing:
The first line opens the form in Design view, thus removing the temporarily assigned RecordSource. When you then open the form again in Form view, it is using its default RecordSource i.e. the entire "Table1".
The report isn't showing just the newly added rows, it's showing the entire table.
The situation you're in right now is that you want:
• To perform a search, get results in a form which limits displayed rows to that search.
• Add rows which do not conform to that RecordSource (so that if the search were performed again - it would NOT show those... THIS is what I confirmed with you earlier WAS happening. :-s)
• Open a report based on that same passed RecordSource, but ignore the fact that some recent rows don't match that recordset - and instead include them, even though they could be entirely random.
Does that highlight the problem?
Are there solutions (workarounds)? Yes of course.
I can think of two obvious ones off the bat.
Firstly, iterate the Result form's rows and build a new criteria from the entered values.
Secondly, use an unbound report. (Far from standard, but this is going against the grain for data requests.)
See example for both options.
Cheers