> Without knowing too much about this stuff, my first thought would be to
have
> a hidden field or a URL parameter that holds the current record or page,
and
> have this passed back to the CGI or ISAPI app when the user clicks forward
> or back.

Pretty much the case.... If you hold session state (ala ASP or JSP, or
servlets, for that matter) you could hold it in there, but there isn't much
point. Just specify a record to start on.

> Now since ISAPI and CGI apps are stateless... do developers actually rerun
> the previous query and, if looking at the 3rd page say, then go forward 21
> recs and start showing the next 10 records from there???

yup. There are various ways, but it depends on what you are doing.

you can requery the database each time. If the user inserts a record in
postion 1, and you are after record 10, then tough, you miss a record, or
get 9 twice.... not really a biggie.

you can keep the results of the query in server-side state, if whatever you
are doing it with supports it (CGI does _not_, ISAPI may but you might have
to hack it, ASP, JSP and Servlets definatly do). Thats nice, consistant and
quick if you have a lot of RAM (or a small number of users), and its nice
and easy on your database. I've done this with a 3 tier system, which worked
even better - the query took about 15-30 seconds to run anyway, over 30000
records.... the other problem with this way is you need to load the entire
recordset into memory - not a quick option.

see why connection pooling as an absolute _must_, and why CGI sucks so badly
(no option for connectionpooling, 'cos the app is loaded and unloaded each
time, where as DLL's are kept around)

> My question is, first, is this how people do it, and secondly, what if a
DB
> user adds or deletes records in the mean time, the records shown from the
> CGI or ISAPI app could then have duplicates or miss out records etc...

all you can care about is the state when the query goes out the port - if
the user then clicks on a item that has been deleted since they did it, you
need to handle it with a "sorry, thats history" type message....

BTW, I can't anit-recommend CGI enough - its not a good option at all. ISAPI
is OK, but its a LOT of work....

N

---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"

Reply via email to