|
Una recomendación, ese efecto de "speed search" o búsqueda rápida es vistoso pero inútil al final porque el locate solo busca lo que empiece con lo que escribas en el TEdit. Si tu tabla solo tiene unas cuantas filas, al final si puede ser útil, pero si es una tabla con miles de registros no veo el caso e usar un grid para mostrarlas todas si al final el usuario no quiere verlas todas sino una o dos. Cuesta trabajo conceptualizar un diseño en donde los grids se usen únicamente para mostrar resultados de búsquedas y no como la fuente donde el usuario va a buscar. Te pongo un ejemplo, es como si le das al usuario la guía telefónica y le pides que ahi el busque el nombre que desea, cuando esa búsqueda la puede hacer el sistema.
Lo que yo recomiendo casi siempre es usar uno o varios TEdits para pedir al usuario que escriba los criterios de búsqueda. Tratándose de nombres o campos que contienen solo texto le pido que ponga solo la parte que más lo identifique, no necesariamente las letras con las que comience. Por ejemplo si busca "MARTILLO DE UÑA", bastaría conque pusiera "UÑA" o "MARTILL". Lo que hago en el query es hacer un LIKE para que me devuelva todos los registros que contengan esa subcadena. El resultado lo muestro en un grid y de ahi ya puede el usuario seleccionar el que desee ver o editar. Además tenemos la ventaja de que en el grid mostramos únicamente las columnas relevantes no necesariamente todos los campos, pues por ejemplo un registro podría tener que será, unos 40 campos distintos y mostrarlos todos no tendría caso. De esta forma optimizas la velocidad de tu aplicación, el uso de memoría y las querys son mucho más rápidas, más a aún si es un sistema que funciona en línea.
Mi regla de oro para este tipo de casos es traer del servidor la menor cantidad de datos posibles.
|