Si quieres mostrar los datos del registro activo del query en unos edits con el objetivo de que el usuario pueda verlos y modificarlos debes tener lo siguiente:
1. Dicho Query debe contener la consulta SQL SELECT correspondiente
2. Este mismo query debe estar abierto
Cuando se abre el Query el primer registro está "activo" por lo que una lectura de los campos como la que haces en tu código que nos muestras hará que en el edit en cuestión aparezcan estos datos.
Ahora bien, cuando te muevas entre los registros del DBGrid deberás "actualizar" el contenido de los edits. Una posibilidad de hacer esto es implementar justamente el evento OnAfterScroll, y ahí mismo leer el registro "reposicionado". La otra posibilidad es emplear el mecanismo que te ofrecen los data-ware: usar un DBNavigator, un TDataSource, y unos DBEdits, que solitos hacen "el trabajo sucio" que estás implementando.
Para que esto funcione, naturalmente el Query debe estar en todo momento abierto.
Lo que sigue es disponer de un botón "Editar" y ahí mismo poner el Query en modo de edición (si es que lo permite... no todos los tipos de consultas son actualizables) y hacer el paso inverso: pasar el contenido del edit (cambiado o no por el usuario) al respectivo campo y confirmar.
Ahora bien, por seguridad yo te aconsejo emplear otro Query distinto. Es lo que hacemos muchos: Tenemos querys, tables, etc. para cada cosa: insertar, mostrar, actualizar, borrar, para consultas tipo informes, para filtrar, etc. Y lo que hacemos es abrirlos y cerrarlos en los momentos oportunos.
Llamemosle QueryActualizar que tenga una SQL del tipo UPDATE. A éste Query se le pasa el contenido de los edits, y se ejecuta la consulta. Para que esto funcione naturalmente tal consulta SQL UPDATE debe tener en su parte WHERE las condiciones necesarias para identificar de forma inequívoca al registro en cuestión. Razón por la cual es que se aconseja sabiamente emplear los dichosos campos IDs que tu aún te resignas utilizar. Sin ese campo ID la cosa se hace más complicada, porque ahora deberás tener un WHERE que contemple todo los campos antes de la modificación. En sintesis algo como:
UPDATE TABLE <NombreTabla>
SET Campo1=<Valor1>, Campo2=<Valor2>, ...
WHERE (Campo1=<Valor1AntesDeCambiar>) AND (Campo2=<Valor2AntesDeCambiar>) ...
Es decir deberás tener unas variables (tantas como campos se necesiten) para almacenar temporalmente el contenido de los campos del registro leído, y de esta forma poder indentificar el registro que queremos modificar ¡Sin el WHERE (o un mal condicional) podrías llegar a alterar otros registros o hasta incluso TODOS!. Y obviamente, cuando se mueve de un registro a otro del DBGrid también debe irse "actualizando" estas variables.
Con un campo PRIMARY KEY la cosa es más sencilla. No hace falta tanta evaluaciones, simplemente un WHERE como esto:
...
WHERE (ID = IDEnCuestion)
Naturalmente, ese ID no debería ser modificable bajo ningún motivo.
Según yo recuerdo tu tienes definido como PRIMARY KEY al campo Nombre. No es tan mal, pero imagínate el siguiente escenario: en una Oficina de Registro Civil llega un padre contento para anotar a su primer hijo recién nacido. El nombre elegido es Miguel Lopes. (Si, con Lopes, con s y sin acento en la o), el agente social que lo atiende escucha el nombre y lo graba como Miguel López. El padre no se da cuenta del error, y se va ya con la partida de nacimiento y el DNI confeccionado.
Vuelve al día siguiente con el humor cambiado, y pide que le cambien el nombre... ¡El es descendiente de portugueses no de españoles! Es Lopes, no López. Los que diseñaron el sistema pusieron como clave primaria el nombre.... el desastre viene cuando hay el sistema no les deja alterarla.
Otro escenario: Al intentar ingresar el nombre como Miguel López, el sistema detecta que ya hay una persona con el mismo nombre... un tipo de 34 años. Ya vez porqué nunca es buena señal que los nombres sean claves primarias.
Para finalizar, no quisiera terminar mi post si hacerte una fuerte crítica. Ya sabes como son las cosas en el foro dooper. Sin decirnos el error, y sin aportarnos mayores detalles que nos den un panorama más amplio es difícil que lleguemos a predecir efectivamente cual es el problema que tienes. Esa simple línea de código no nos dice nada.
Saludos,
.
el código generado es este
