[[Lepe]]

No estoy de acuerdo con todo lo que se dice por aquí y como esto es un foro, doy mi opinión.

La verdad es que todos llevan razón, incluso tu amigo que dijo que no usaras DBEdits, pero hay que explicar el por qué no usarlos y también cuando sí usarlos.

Empezado por Forest

Tabla.Fields[numero].Tipo¿? ... la verdad no se, no conozco estos comandos. No se si alguien me pueda aclarar por qué se hace referencia a los campos de esa forma.

...Porque le da la gana .

Tienes varios métodos para acceder a los campos:
1- campos persistentes (doble clic al TTable y después en el Field editor boton derecho y Add All Fileds). Así accedes al campo:

NombreTablaNombreCampo.AsXXX

Ésta si cabe, es la forma más rápida y eficiente de acceder al campo. Fíjate que no hay un punto entre el nombre de la tabla y el nombre del campo, el nombre es todo uno (es la forma de delphi de nombrar los campos).

2- Por el índice de la lista de campos, es casi igual de rápido que el método anterior, solo ha de accederse a la lista Fields, ver que el índice (en este caso el cuarto campo) es válido, y se accede a él:
Fields[3].AsXXX

3- Por el nombre del campo, aquí primero se ha de buscar si ese campo existe y después se accede a él:

Tabla.Fields['NombreCampo'].Asxxxx

Y por último, otro que se usa mucho:

4- tabla.FieldByName('NombreCampo').Asxxx que también implica hacer una búsqueda para ver si ese campo existe en tiempo de ejecución.

Puedes usar el que te sea más cómodo.

Empezado por Forest

Y otra cosa, cuando yo comencé me dijeron que no usara los DBEdit y DBLabel, no se por qué, pero me lo dijo alguien con más experiencia y le hice caso, y es por eso que trabajo de esa manera en vez de accesar directamente a la BD.

Si usas Paradox y la aplicación es pequeña o mediana, te conviene usar DBEdits, ahorran mucho trabajo. Cuando la aplicación crece en tamaño, necesitas hacer operaciones en memoria con los datos, mostrar la información de otra forma en que está almacenada, etc, entonces es el momento de olvidar los DBEdits y trabajar con Edits. Un ejemplo típico:

Tienes una agenda y en la base de datos lo guardas así:

fecha		hora	tarea
01/01/2008	15:00	Ver la novela :-P
01/01/2008	17:00	Ver Barrio Sésamo :-P
02/01/2008	15:00	leer el periodico

y quieres mostrarlo al usuario así:

	01/01/2008			02/01/2008			03/01/2008
15:00	Ver la novela :-P		leer el periodico
17:00	Ver Barrio Sésamo :-P

Esto no puedes hacerlo con un DBGrid porque los días están en filas y quieres mostrarlo en columnas, así que te olvidas de los controles de DBAware y lo haces con un StringGrid.

Dentro de un programa, puedes tener una ventana donde usas DBEdits y en otra ventana no usarlos. No hay ningún problema en mezclar las filosofías de trabajo.

2. ¿Tiene alguien idea de que de malo pueda tener usar los DBEdit o DBLabel? ¿se puede corromper la BD por un mal uso de estos o algo así?

No usar DBEdits supone más trabajo. Estas 4 líneas lo hace automáticamente los DBEdits junto con un TDBNavigator:

Código Delphi [-]
Datamodule.Tabla.Insert //o .Edit según se requiera insertar o editar el registro
Datamodule.TablaCampo1.value:= Edit1.text;
Datamodule.TablaCampo2.value:= Edit2.text;
Datamodule.Tabla.Post;

Pones los DBEdits en el form, configuras su propiedad Datasource y Field, pones un TDBNavigator en el form, configuras su propiedad DataSource. Listo. Abres la tabla en el formCreate y ya puedes:
- añadir registros
- modificar registros
- borrar registros
- moverte entre registros
¡¡ sin escribir ni una sola línea de código !!

Desventajas de usar DBEdits:
- Todo lo que haces se graba directamente en la Base de datos, puede que en algún caso no te interese, quizás puedas usar Cache Updates (busca en el foro por ApplyUpdates) es un método intermedio entre usar DBEdits y usar Edits.


3. Creen que se pueda combinar el estilo que yo uso con este otro para lo que son las Querys por ejemplo, ya que los ADOQuerys que veo en ese tutorial ahorran mucho trabajo (que yo hacía usando ciclos y cosas así x_X)

[/quote]
Por supuesto, Todo los ciclos que haces en paradox puedes sustituirlo por un TQuery. Busca en internet un manual de SQL, en menos de 2 horas verás que son muy potentes y flexibles.


PD. Como un extra, y que tal vez debí postear en el tema del tutorial, alguien sería tan amable de explicarme detalladamente esta query?:

Código SQL [-]
SELECT DISTINCTROW Sum([Banco].[Depósitos]) AS [Suma De Depósitos]
FROM Banco;

Como ya te han dicho, eso equivale a recorrer todos los registros de la tabla Banco, sumar el campo deposito de todos ellos (para saber el monto total) y por último devuelve el total en un campo que se llama "Suma De Depósitos" como bien dices es un "nombre", un Alias que se le da a la suma total.

Cuando un campo lleva espacios en su nombre, se debe agregar los corchetes para que el SQL sepa donde empieza el nombre del campo y donde termina. Access usa corchetes, el SQL estandard usa dobles comillas por lo que puedes escribir ese campo de diversas formas, según el motor de bases de datos que uses.


La palabra "Sum" es una función del lenguaje SQL, también puedes hacer promedios, medias, contar registros, etc con el mismo campo de todos los registros de la tabla. El TQuery es una forma de filtrar registros de una forma más flexible que la propiedad Filter del TTable.