Simplificando:
Ustedes tienen una aplicación que muestra datos paginados cada 10 registros. Eventualmente, el usuario puede borrar algunos de ellos, y lo que desean es que refresque la información de modo que si la acción se realiza en las páginas medias o inicial de las que se muestran, se vuelva a leer lo restante a partir de esa misma página.
Bien. Hay varias formas de verlo, pero a mi entender están complicando demasiado un problema que parece muy sencillo.
Suponiendo que la acción de borrado tiene efecto inmediato en la base:
- Si la aplicación contiene un numero fijo de páginas, no hace falta consultar nada. Basta con multiplicar por diez el número de la página en que está el usuario en ese momento y pasarlo como parámetro a la sentencia que se construye. Ni siquiera requiere el uso de variables de usuario, sino simplemente construir la sentencia SQL con ese valor dado.
- Si el paginado no se mantiene, sino que sólo muestra el segmento consultado, pueden darse cuatro situaciones:
1) se borró el inicio de la tabla,
2) se borró el final de la tabla,
3) se borró el medio de la tabla,
4) Se borró toda la tabla.
Para resolver todos estos casos se necesita nada más que cuando se leyera la tabla, se lean (aunque no se representen) la/s columna/s que sea/n la PK de la tabla.
En el primero, segundo y tercer caso, se debe usar simplemente la PK que corresponde al primer registro restante.
En el cuarto caso se debe conservar momentáneamente en una variable el valor del
último registro y pedir los mayores a:
Yo no le veo sentido, si se construye la sentencia en forma dinámica, en tener que usar sentencias más complejas que eso. Y menos usar dos para lograrlo.
Ahora bien, si y sólo si el borrado de los registros no es físico en la base, puede requerirse un campo de estado en la tabla que determine si es accesible o no para lectura.
¿Es borrado físico o lógico?