Let's not call these database 1 and 2. The reason for not doing that is that a "database" is more than a single table. It can even be more than a single file, it can be a system of many files with many tables in each file, all linked in relationships.
You have a customers table and some kind of sales table. (sales info often consists of more than one table--often a system of 3 related tables.)
The relationship linking them should be similar to this:
Customers::CustomerID = Sales::CustomerID
Customers::CustomerID should be an auto-entered serial number. Sales::CustomerID would be a number field, NOT an auto-entered serial.
You might thing that your report layout should be based on Customers, but it's often better to base it on the Sales layout.
Create a layout based on Sales. That means that "sales" is selected in "Show Records From" in Layout Setup... Use Part SetUp to add a sub summary part "when sorted by" CustomerID. Use the "print above" option so you can list the sales info below this sub summary part.
Add the fields you want from Customers to this sub summary layout part. Add the fields you want from sales to the body layout part below it. If you define summary fields in Sales, you can include summary info for a given customer such as totals, averages, etc and can place them in the sub summary layout part (or even add a second such part with Print below to show totals below each customer's data.)
When you return to browse mode, always sort your records by the "when sorted by" field you selected for the sub summary part or that layout part will not be visible in browse mode or when you preview/print/PDF your report.
Before adding the ability to click a row and see the full info on that sales record, get that portion of your project working and then report back. It's quite possible that parts of what I have just outlined need to be described in more detail. If so, feel free to use the Post A Answer box to post follow up quesitions in order to get a more detailed description.