yes, kostya is correct in that...the caveat is that Crystal by itself will not write out to the database. It will only query the database once per report, which is why if you use a stored procedure you could write to the database.

Again, what Kostya is saying about a constant number of records per page will allow you to 'guess'/'predict' what the page number will be. If you have fields that 'Can Grow' the results can be unpredictable. CR is a pain that way.

Again, the hard part is guessing what page a record is on, and then writing that to a table, just because the actual result will basically be unknown until it's too late (ie after CR has formatted the report).

Hopefully, your report will be 'well behaved' and you will be able to find an algorithm that closely matches the actual page printing. All sorts of things can affect this, 'Keep Together', 'New page before', 'new page after' different fonts/bold/italic. These are just the items off the top of my head that can help/confuse the algorithm.

How could they help? Let's say that you have a new page before each group, and that the details always stay on the same page, then it is pretty easy to predict what page each group will be on.

On the other hand, you several nested groups with new page before and can grow fields and keep together and unknown number of details, it would be a very complex task to determine what page anything is on.

Not meaning to scare you, just that this could be a very difficult task.