Dudas con Locate

[Carlex]

Hola buenas, resulta que me percate de un error(talvez) o algo este mal que no comprendo estoy ingresando datos con un formulario y me interesa saber si la llave es duplicada, ahora bien hay dos formas una capturando errores y otra con una busqueda rapida con el locate, aqui viene la duda o error, si sentencia es la siguiente

dm1.TSector.Locate('S_Sector', DBedit1.text, [loCaseIntensive]);

el programa 1ro realiza esta sentencia para ver si ya existe la llave si la hay despliega un MSG, pero al usar un DBEDIT guarda el dato a la BD, antes de la busqueda, porque? usando en ves de un DBEDIT, un EDIT1.text no hay problema, a que se debe esto? estoy con SQL Server 2000.
Es mejor usar el capturado de errores en este caso?

Y otra consultita, en SQL SERVER y Access como se resetea a 0 un campo autonumerico, es decir si borro un registro al ingresar uno nuevo continua el correlativo desde donde se quedo (1,2,4,5,etc), Muchas Gracias

[[eduarcol]]

Pues si tienes razon, hay un error, solo espero que no pienses que el error es de Delphi, el error es el tuyo:

Al tener un dbEdit conectado a la base de datos cualquier cosa que escribas ahi se va a reflejar en la tabla, por eso es que te funciona bien en el edit

Una observacion: Si tienes un motor de base de datos tan poderoso como SQL SERVER porq utilizas un locate , pienso que estas subutilizando los recursos

Otra cosa te recomiendoesel manejo de errores

[marcoszorrilla]

Esto pasa con cualquier base de datos, lo que ocurre es que Locate mueve el puntero y por lo tanto se produce un Post.

Una solución puede ser utilizar un segundo Ttable, o una query para hacer esta labor y así quedaría resuelto el problema.

Un Saludo.

[jachguate]

Hola.

Si queres buscar si una clave ya está duplicada... no podes hacerlo en el mismo dataset, pues al lanzar el locate, el estado cambiará de dsInsert (o dsEdit) a dsBrowse, y esto povocaria un Post automáticamente.

Usá otro dataset apuntando a la misma tabla... o bien un query "especializado" que reciba como parámetro el dato a buscar.

Por otro lado, no es aconsejable usar la propiedad Text del dbEdit. Dado que este está asociado a un valor en un DataSet, es mejor usar directamente este.

En lugar de

dbEdit1.text

Tabla.FieldByName('campo').Value o bien
dbEdit1.Field.Value

Para la otra pregunta, tal como lo indica la guia de estilo, mejor abrí otro hilo.

hasta luego.

[Delfino]

El metodo lookup no mueve el cursor y a lo mejor puede servirte en este caso, no lo ha probado pero creo q puede servir..

[jachguate]

Bueno... probablemente el método Lookup deje el dataset en el mismo registro... no se, pero dandome una vuelta por el código de la vcl, he visto que, al menos en la implementación del BDE (TBDEDataSet) en la unidad dbTables.pas, internamente se mueve el cursor para ubicar el registro (hay otra forma?)

Esto tiene el efecto de hacer post antes de poder mover el cursor. Desconozco otras implementaciones, y no tengo tiempo para buscar ahora, pero estoy convencido que siempre harán post primero.

Por ello, como ya dije antes, es mejor valerse de otro dataset o de un query direto a la bd.

Hasta luego.

[Carlex]

Buenas, gracias por las respuestas, al final termine realizando la validacion capturando el error, pero hasta donde lei en el manual de delphi, el locate es una funcion muy rapida para encontrar una llave o campo, y si estoy usando SQL server 2000 es por que debo manejar un a BD de mas de 80 mil datos, y mi preocupacion es que las busquedas tarden demasiado, por eso no use un query, ya que en algunas tablas debo controlar la duplicidad de una llave, en otros casos un campo X. Para el caso de las llaves capturando errores se soluciona, pero en el otro caso de un campo que no es llave, usar el locate no se si es adecuado.

[jachguate]

Empezado por Carlex

pero hasta donde lei en el manual de delphi, el locate es una funcion muy rapida para encontrar una llave o campo

Yo diría que el locate es una función que te permite encontrar de manera fácil un registro en base a cualquier campo... pero de eso a que sea muy rápida..., yo diría mas bien, ineficiente. Esto lo digo por definición... ya verás.

Empezado por Carlex

y si estoy usando SQL server 2000 es por que debo manejar un a BD de mas de 80 mil datos

Has considerado otras opciones?
¿Firebird por ejemplo?

Empezado por Carlex

y mi preocupacion es que las busquedas tarden demasiado, por eso no use un query, ya que en algunas tablas debo controlar la duplicidad de una llave, en otros casos un campo X.

Creo que en ningun caso puede ser mas rápido un método de búsqueda en el cliente que un query contra el servidor. El cliente no tiene mas que un mar de datos en los que moverse secuencialmente, además, deberá hacer viajar por la red tantos registros como sea necesario para ubicar el buscado. En cambio el servidor, tiene a su disposición indices y un motor de optimización de consultas que por algo se habrán matado los programadores haciendo...
Además de tener los datos en el disco local y, dependiendo de las características del motor, hasta podria mantenerlos en memoria RAM (si son datos de acceso frecuente).

Lo que hará falta es que tengas los indices adecuados para que las consultas que lances puedan obtener una respuesta rápida.

Es mi opinión personal, claro. Puede que haya alguna implementación eficiente del locate (depende de las clases de acceso a datos que uses)... pero no se me ocurre una implementación eficiente que no se valga de un query directo contra la bd...

Hasta luego.

[marto]

Wop!

Juan Antonio, creo que te pasas de prudente: lo que comentas no es una opinión, sencillamente es así.
Solamente se me ocurren dos situaciones en las que pueda ser más rápido un Locate que una query (hablando de servidores, claro): o bien te has tenido que bajar previamente TODA la tabla por algun oscuro motivo que no logro imaginar (y pese a todo tendría que ser una tabla no demasiado grande), o bien se tendría que tratar de una tabla muy pequeña (pero mucho eh! ).
Lo que sucede es que mucho me parece a mí que el compañero está trabajando con TTable, y claro, si empiezas mal los planos... seguro que no te sale un palacio (con todos los respetos).

Por otro lado, ni hacer un locate ni lanzar una query me parece un método serio o seguro para controlar duplicidades, ya que si el sistema soporta concurrencia nadie nos asegura que ese valor no se haya introducido en otra transacción aun sin confirmar.

[marto]

Empezado por Carlex

pero hasta donde lei en el manual de delphi, el locate es una funcion muy rapida para encontrar una llave o campo

¿Es posible que eso lo leyeses en relación al trabajo con tablas planas (Paradox, dbasem Access...)? Por que en ese ámbito sí es cierto, ya que de todos modos el trabajo siempre lo hace el cliente!!!!!

[jachguate]

Empezado por marto

¿Es posible que eso lo leyeses en relación al trabajo con tablas planas (Paradox, dbasem Access...)? Por que en ese ámbito sí es cierto, ya que de todos modos el trabajo siempre lo hace el cliente!!!!!

Aún en ese caso, no estoy seguro si sería mas rápido el locate que el query, o si simplemente daria lo mismo...