> The user won't be setting the thumbs per page option, I will as the album
> admin. I could calculate what page a particular image would fall on and
> always be right. However, that would take three steps:
>
> 1. sql to get list of picids
> 2. find the current picid in that array (finding that it's picture number
> 32)
> 3. divide per page number by the location step 2 found and rounding up
>
> That just seems like an aweful lot of code to figure it on the fly when I
> could pass the last page you touched on to the next page one line of code.

That can be done in single SQL query in Oracle 8i.


> Keeping in mind that I never indicated that the picids were perfectly
> sequential.

I didn't assume that.


> They usually will be, but if I delete a picture or add one
> later then that would introduce picids that were not perfectly meaning of
> their position in the set. I can't rely on assuming that picid 32 is
> actualy the 32nd picture in a set.

I know. Also because the pictures may be ordered by name/description/date,
not by ID on the page. I assumed only that we have the information
about the exact order of pictures. I mean that for example we know for
sure that one picture will be before some another picture because
they differ by at least one parameter, which means that ORDER BY clause
has to include a list of parameters which has distinct values. For
example we order the pictures by date (when the picture was taken),
name and ID. Ordering by only date would not be enough because many
pictures could have same date. If the "name" field can be same for
many pictures with the same date, then we'll have to add something
more. I added ID because I assume it's the primary key in this database
table. In order by clause I always include all columns from some unique
constraint to make sure that the order is perfectly defined. In many
cases this means that I have to include primary key columns in order
by because in many cases it's the only unique constraint in the table.


> If I deleted a previous pic, then number
> 32 might now be in the 31st position unless I rename all my pictures
> everytime I remove one - and that seems like overkill.

If calculating the page number is difficult (our DBMS does not
allow you to perform this calculation and you have to do it in PHP),
then do the calculation only when it's really needed. Which means
that when a user is on some picture page and the page has to have
links to thumbpage and setpage, then do not calculate pagenumber for
those links, but include picture ID in the links. The thumbpage
and setpage script would have to be able to display proper page
when given page number and also when given picture ID. This way
the calculation is made only when the user clicks thumbpage or
setpage link. (In case of setpage it should also be able to calculate
page number based on thumbpage number to make the same mechanism
work when going back to setpage from some thumbpage.)


> $SESSION variables seem like the way to go since the user can't change the
> thumbs per page, only I can, and even if they could, it wouldn't be on the
> fly, they'd have to go to a 'settings' menu and start their browsing over
> again so the $SESSION problem mentioned won't be an issue for me.
>
> My problem at this point though is properly using $SESSION as I stated in a
> message parallel to yours in the reply tree.
>
> I've got a seperate thread started on clarifying $SESSION usage so I won't
> state it again here.

Yes, $_SESSION may be the solution. I saw your thread about it, but I'm
not able to help in this case.


Hilarion