When a single-page form expands to more than one page, can you reference the new individual "pages" that have been created by the expanding table?

Question

Don't think this is possible but would love to be wrong.
Bullet Points:
1) In my demo form (simple hierarchy: form1.page1.table1.row1), 8 occurrences  (instance "0" through instance "7") of the repeating row1 can be visible
     before it causes a page break and adds another "page".  No issues there.
2) I'm thinking about trying to control the end-users navigation abilities to only on-screen "previous page" and "next page" buttons.
     (So no scrolling from page to page; keep them where we want them.) Only way I can see making this work is if the form is designed
     and coded to only allow one page to be visible at a time --- nesting things correctly in a parent object then hide all necessary subforms
     and only make the appropriate subform visible.
3) But when working with tables,  when occurrence 9 gets added (aka instance 8), it triggers an on screen "Page 2" to be added.
     End user can now scroll between Page 1 and Page 2. 
4) Once Page 2 has been added, is there a way to reference Page 1 (as we see it on screen) and set it to be hidden?
5) Is what we are seeing on screen as "Page 1" and "Page 2"  actually this.resolveNode("page1[0]") and this.resolveNode("page1[1]") ?
     Tried messing around with referencing it this way but didn't seem to work.  Maybe I had a typo but if we never set the subform named "page1"
     to allow multiple instances, I'm guessing it's not referenced this way.
Any thoughts would be great.  Thanks so much to this community.
Brian

Answer 1

If you're looking at learning a bit more about database design (looking at your description of what you've done in creating a separate table for each category of item sold sounds like you're approaching it as though it was a flat-file rather than a relational database), there's a few books that I could direct you to:
Beginning Database Design (ISBN 978-1590597699)
Database Design for Mere Mortals (ISBN 978-0201694710)
Databases Demystified (ISBN 978-0072253641)
Absolute Beginner's Guide to Databases (ISBN 978-0789725691)
I've also got an older book that's always sitting by my desk called Dreamweaver MX Databases (ISBN 978-0782141481), which I still reference regularly - chapter 3 on coding practices and chapter 5 on database design provide very good overviews of the subject.
There's also a Database Development for Dummies, but I'm not a huge fan of the series where they're tackling technical subjects.
Without knowing the data you're modeling, it's quite difficult to make generalisations, but I'd probably be looking at a single table called 'Product' (which contains all the product records), and which had in it a boolean for 'new item' and for 'on sale' (you could then use SQL to filter out new and/or sale items when you create your recordset). I'd then have a look up table called 'Categories' which held the values 'necklace', 'handbag', 'belt', and 'purse' which the Product table could then reference to identify.
Breaking your data down into a logical structure like this is called 'normalisation' (see http://en.wikipedia.org/wiki/Database_normalization) - although it's a bit technical. There's a simpler practical explanation of a similar query to yours at TechRepublic (http://articles.techrepublic.com.com/5100-10878_11-5288500.html), which uses MS Access, but don't worry about that as it's teaching a concept which is applicable no matter what the database server.