curiosidad de FieldbyName

[Lepe]

Holas amigos:


He visto que en la mayoria de los mensajes siempre usais la sintaxis:


tblClientes.FieldbyName('Observaciones')



Pero tambien se podria usar directamente :

tblClientesObservaciones


Hombre, con el método 1 se podría acceder a cualquier campo que se tuviese en un String, por ejemplo.

Aparte de eso, hay alguna razón más para usar el método 1 con algunas ventajas respecto al 2 ??

[__cadetill]

Hola

de echo, no, no hay ninguna ventaja en el comportamiento de un programa.

Diferencias.

Con la primera : como tu bien dices, puedes pasar una variable de tipo string que contenga el nombre del campo para acceder a él. Tampoco necesitas declarar los campos persistentes (por ejemplo, una Query que utilices para vairas consultas y que no devuelva los mismos campos). Desventajas -> si pones mal el nombre de campo, no te enteras hasta la ejecucion del programa

Con la segunda : si pones mal el nombre del campo (o si no existe o lo borras de los persistentes), con una simple compilacion te enteras.

Cada una tiene sus ventajas y desventajas a la hora de programar y, creo que es mas una costumbre de cada uno que otra cosa. Yo, por mi parte utilizo casi siempre la segunda (excepto en los casos de las Querys que te comentaba). Quizas por aqui se utiliza mas la primera para que quede bien claro cual es el Dataset y cual es el Field, no te sabria decir ;)

Por cierto, te has dejado una manera de referenciar a los campos de un Dataset : DataSet[NombreCampo]

Pues nada, espero te sirva de respuesta

[marcoszorrilla]

Alguna diferencia:

ShowMessage(table1.FieldByName('name').asstring);

Este primer ejemplo no se quejaría en tiempo de diseño, pero fallaria en ejecución si por un casual el campo "Name", no se llamara de esta manera.


ShowMessage(table1name.value);
Este segundo a condición de crear campos persistentes, nos daría un error al compilar si el nombre del campo fuese erroneo.

Veo que se me adelantó nuestro compañero Cadetill, yo también utilizo esta segunda notación.


Un Saludo.

[kinobi]

Hola,

añadir a lo comentado por Marcos y Cadetill, que los campos persistentes "pueden" tener un acceso más rápido al valor que almacenan (una llamada a un método Value o As...., por dos llamadas en el caso de FieldByName('NombreCampo').Value/As...), pero, por contra, tienen un consumo de recursos mayor, ya que se crean (en la creación del formulario o modulo de datos) tantos objetos TxxxxField como campos persistentes haya y en el caso de FieldByName se utiliza directamente el objeto TDataSet correspondiente.

Yo, al contrario que los compañeros, suelo utilizar la opción FieldByName. Para minimizar posibles errores de tecleo en los nombres de los campos suelo utilizar constantes.

Saludos.

[JavierB]

Hola.

Yo utilizo una tercera opción que me parece que no se ha comentado aquí.

Table1.FindField('Nombre').AsString;

No se cuales pueden ser las ventajas y los inconvenientes :confused: pero lo pongo por lo que pueda valer.

Lo que no he entendido es el comentario de kinobi de que utiliza constantes para evitar errores en los nombres de los campos. Si alguien pudiera aclararlo...

Saludos,

[kinobi]

Hola,

Posteado originalmente por JavierB
Lo que no he entendido es el comentario de kinobi de que utiliza constantes para evitar errores en los nombres de los campos. Si alguien pudiera aclararlo...

en vez de utilizar:


DataSet.FieldByName('MiCampo').AsInteger;


utilizo una unit con constantes:


Const
cMiCampo = 'MiCampo';


y después, donde necesite ese nombre de campo, utilizo la constante:


DataSet.FieldByName(cMiCampo).AsInteger;


Así minimizo los errores de ejecución por teclear mal el nombre del campo, ya que si tecleo mal el nombre de la constante, el error saltará en compilación.

Además, si cambio el nombre del campo en la base de datos, sólo tengo que cambiarlo en un sitio en la aplicación, en la unit de constantes, y no recorrer todos los fuentes buscando los "FieldByName" para cambiar el nombre del campo.

Evidentemente sigue existiendo el problema de escribir mal el nombre del campo en la unit de constantes, pero al menos es en un único sitio centralizado.

Saludos.

[andres1569]

Hola:

Por cierto, hay una diferencia entre FindField y FieldByName. El primero devuelve nil si no ha encontrado un campo con ese nombre, por lo que nos permite esquivar el mensaje de error. FieldByName en su implementación llama a FindField y si devuelve nil lanza una excepción.

Una técnica que utilizo a veces, cuando voy manejar un campo varias veces es llamar a FindField y almacenarlo en una variable de tipo TField, para acelerar luego las operaciones sobre el mismo.

Saludos

[kinobi]

Hola,

Posteado originalmente por andres1569
Por cierto, hay una diferencia entre FindField y FieldByName. El primero devuelve nil si no ha encontrado un campo con ese nombre, por lo que nos permite esquivar el mensaje de error. FieldByName en su implementación llama a FindField y si devuelve nil lanza una excepción.

En ese sentido, FieldByName está más en la línea actual de gestión de errores (excepciones), al "obligarte" a utilizar un bloque try ... except para capturar la excepción y actuar en consecuencia.

Saludos.

[JavierB]

Hola, kinobi.

Gracias por la explicación. Un método muy útil, ciertamente.

Saludos,

[pedrohdez]

Hola,

Kinobi
pero, por contra, tienen un consumo de recursos mayor, ya que se crean (en la creación del formulario o modulo de datos) tantos objetos TxxxxField como campos persistentes haya y en el caso de FieldByName se utiliza directamente el objeto TDataSet correspondiente.

Tienes razon solo en parte, en cuanto abres el TDataSet se crea la estructura de TFields correspondientes, asi que salvo que estemos hablando de un TDataModule con muchos TDataSet de los cuales solo se usen unos pocos, el consumo de memoria es practicamente el mismo, solo hay diferencias en el momento de ese consumo, al crear el form o al abrir los DataSet.
Yo uso habitualmente el segundo metodo, el de crearlos persistentes, esto me permite asociarles formas de presentación, validaciones, tamaños al mostrar en un grid etc. pero tienen un problema importante, si cambias el tamaño de un campo, pongamos que un texto de 20 a 40 caracteres, si te olvidas de corregir alguno de estos campos persistentes te encontraras con bonitos errores de violacion de memoria en tiempo de ejecución en cuanto un valor sobrepase los 20 caracteres iniciales.
Ademas, se os ha olvidado un tercer metodo de acceso, "a pelo", por su posicion DataSet.Fields[0] yo lo uso mucho en procesos internos.

PD. por cierto, a ver si alguien me dice como se pone eso de "posteado por fulanito" que no lo encuentro la opcion.

[roman]

Posteado originalmente por pedrohdez
PD. por cierto, a ver si alguien me dice como se pone eso de "posteado por fulanito" que no lo encuentro la opcion.

¿Algo así como esto? :)

Usa la opción "Citar"

// Saludos

pd: Por cierto, me parece que en la guía de estilo se habla de usar la lengua de Cervantes y García Márquez. Como dudo que ellos usaran la palabra "postear" propongo, si es posible, que la cambien por algo más cervantino. :p

[pedrohdez]

Hola Roman,
Pues sera el mozilla, pero cuando le doy a citar me sale un cachumbo con un quote y un hueco para poner el texto a citar, que es lo que he usado, pero en ninguna parte aparece que estoy citando a nadie
¿alguna sugerencia?

[__cadetill]

Posteado originalmente por pedrohdez
Hola Roman,
Pues sera el mozilla, pero cuando le doy a citar me sale un cachumbo con un quote y un hueco para poner el texto a citar, que es lo que he usado, pero en ninguna parte aparece que estoy citando a nadie
¿alguna sugerencia?

Hola pedrohdez

Roman se referia al boton de "citar" que hay debajo de cada mensaje, no en el que hay cuando estas componiendo el que tu escribes, sino el que hay abajo a la derecha de cada mensaje que estas leyendo

[Alfredo Soler]

Saludos.

Yo al inicio utilizaba el segundo método el de crear los campos persistentes, me encontré con el problema de tener una aplicación que utilizara MS-SQL o Access y en algunos tipos de campos me arrojaban errores cuando abría la base de datos, porque el tipo de declaración debía de ser diferente para cada tipo de conexión de DB.


pedrohdez
Yo uso habitualmente el segundo metodo, el de crearlos persistentes, esto me permite asociarles formas de presentación, validaciones, tamaños al mostrar en un grid etc. pero tienen un problema importante, si cambias el tamaño de un campo, pongamos que un texto de 20 a 40 caracteres, si te olvidas de corregir alguno de estos campos persistentes te encontraras con bonitos errores de violacion de memoria en tiempo de ejecución en cuanto un valor sobrepase los 20 caracteres iniciales.

Con respecto a lo que dice pedrohdez pienso que existe una mayor dependencia de la base de datos al trabajar con este método, y una de las características de la programación actual es que los programas dependan poco de cambios que se realicen en la DB ya que con un solo cambiar el tamaño de un campo una aplicación que puedas tener instalada en muchos puntos de la red puede darte problemas.

[Lepe]

Hola foreros, ¡¡¡ ESTO SI QUE ES UN FORO!!! Lo demás es tonteria :D

No solo me habeis respondido sino que además se ha formado un pequeño debate sobre el tema, muy constructivo y didáctico para mi, y según he podido ver en los mensajes también para los demás ;)


Muchas Gracias a todos !!

[rlima1978]

Mais uma forma:
ds.FieldValues['Texto'];
Esta função retorna um campo variant. Por este motivo deve-se tomar cuidado nas atribuições:

i: integer;
s: string;
i := ds.FiledValues['CampoInteger']; //ok
s := ds.FieldValues['CampoString']; //ok

i := ds.FieldValues['CampoString']; //VariantTypeCastError

[]

[pedrohdez]

Hola

Escrito originalmente por Alfredo Soler
.. una de las características de la programación actual es que los programas dependan poco de cambios que se realicen en la DB
Y no solo de la programacion actual, el problema es cuando tienes que mostrar datos en un grid, por ejemplo y no quieres ni los anchos por defecto ni los nombres de los campos originales, o bien quieres que un campo logico ponga Si o No en lugar de uno o cero, o bien algun campo calculado ... vamos montones de casos en los que los campos persistentes te ahorran trabajo, sin obligarte a poner un monton de codigo de inicialización en cada una de esas pantallas, con el riesgo de equivocarte en el nombre del campo y que el error no te lo de al compilar si no al cliente cuando ejecuta esa opción.

Todo se reduce a sopesar ventajas e inconvenientes para caso concreto.

[kinobi]

Hola,

Posteado originalmente por pedrohdez
Tienes razon solo en parte, en cuanto abres el TDataSet se crea la estructura de TFields correspondientes, asi que salvo que estemos hablando de un TDataModule con muchos TDataSet de los cuales solo se usen unos pocos, el consumo de memoria es practicamente el mismo, solo hay diferencias en el momento de ese consumo, al crear el form o al abrir los DataSet.

en todo caso, los campos persistentes deben ser creados en el momento de la creación del formulario o modulo datos (y permanecen creados incluso aunque no se utilicen), estén o no abiertos los DataSet's asociados, que a su vez mantienen sus propias estructuras de TFiled's.

Donde no entro es en las posibles ventajas de un método u otro. Confieso que tengo cierta tendencia a minimizar el consumo de recursos en detrimento de otras cuestiones; tal vez sea un hábito adquirido de los tiempos de los microordenadores con escasa memoria.

Saludos.

[roman]

Posteado originalmente por rlima1978
Mais uma forma:
ds.FieldValues['Texto'];
Esta função retorna um campo variant. Por este motivo deve-se tomar cuidado nas atribuições:

i: integer;
s: string;
i := ds.FiledValues['CampoInteger']; //ok
s := ds.FieldValues['CampoString']; //ok

i := ds.FieldValues['CampoString']; //VariantTypeCastError

[]

Yo casi siempre utilizo FieldByName aunque esta forma es la que más me gusta, sobre todo por que FieldValues es la propiedad por default de manera que se puede escribir ds['campo'] en lugar de ds.FieldValues['campo'].

De todas las formas ésta es la que se me hace más clara para legibilidad del código pero se habla muy mal de las "variants". Sin embargo cuando la he utilizado, al menos yo no he notado una baja en el rendimiento.

Lo que indica rlima en cuanto a la excepción puede evitarse en las ocasiones en que podemos sustituir el valor de NULL por 0 en el caso de números o '' en el caso de cadenas fijando la variable global NullStrictConvert a false.

// Saludos