FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
curiosidad de FieldbyName
Holas amigos:
He visto que en la mayoria de los mensajes siempre usais la sintaxis: Código:
tblClientes.FieldbyName('Observaciones') Pero tambien se podria usar directamente : Código:
tblClientesObservaciones Aparte de eso, hay alguna razón más para usar el método 1 con algunas ventajas respecto al 2 ?? |
#2
|
|||
|
|||
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 |
#3
|
||||
|
||||
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. Última edición por marcoszorrilla fecha: 14-05-2003 a las 16:54:48. |
#4
|
||||
|
||||
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. |
#5
|
||||
|
||||
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 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,
__________________
Lo importante no es saber, sino tener el e-mail del que sabe. |
#6
|
||||
|
||||
Hola,
Cita:
Código:
DataSet.FieldByName('MiCampo').AsInteger; Código:
Const cMiCampo = 'MiCampo'; Código:
DataSet.FieldByName(cMiCampo).AsInteger; 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. Última edición por kinobi fecha: 14-05-2003 a las 19:20:56. |
#7
|
|||
|
|||
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 |
#8
|
||||
|
||||
Hola,
Cita:
Saludos. |
#9
|
||||
|
||||
Hola, kinobi.
Gracias por la explicación. Un método muy útil, ciertamente. Saludos,
__________________
Lo importante no es saber, sino tener el e-mail del que sabe. |
#10
|
|||
|
|||
Hola,
Kinobi Cita:
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. |
#11
|
||||
|
||||
Cita:
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. |
#12
|
|||
|
|||
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? |
#13
|
|||
|
|||
Cita:
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 |
#14
|
|||
|
|||
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 Cita:
|
#15
|
||||
|
||||
Hola foreros, ¡¡¡ ESTO SI QUE ES UN FORO!!! Lo demás es tonteria
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 !! |
#16
|
|||
|
|||
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 [] |
#17
|
|||
|
|||
Hola
Cita:
Todo se reduce a sopesar ventajas e inconvenientes para caso concreto. |
#18
|
||||
|
||||
Hola,
Cita:
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. |
#19
|
||||
|
||||
Cita:
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 |
|
|
|