Uso correcto de SQL SERVER

[atani123]

Estoy hecho un lio, para trabajar con base de datos de servidor, concretamente SQL Server hay quien dice que hay que trabajar directamente contra la tabla usando los TDBEdit y demas. Otros me dicen que lo mejor es usar TEdit y luego actualizar mediante Update o Insert.

No se cual es la forma correcta de trabajar contra una base de datos de servidor. Alguien puede pasarme un ejemplo sencillito, en plan videoclub o algo asi donde se demuestre el uso correcto, transacciones, updates, deletes, etc.

Gracias

[Neftali [Germán.Estévez]]

No se trata de correcto e incorrecto. Se trata de que en cada caso puede ser más adecuado lo uno o lo otro.
Sin saber más datos es difícil escoger qué sería lo "recomendable" (que no lo correcto) para tu caso.

* La forma normal es trabajar con componentes de Bases de Datos, que para eso están. Son sencillos de utilizar, están para eso y no tendrás problemas ni errores, puesto que la forma de programar con ellos es bastante "estandard".

* Quien te ha dicho que es mejor trabajar con componentes normales (TEdit) y luego lanzar consultas no está exento de razón, lo que hace falta saber es si en tu caso lo necesitas o no.
Programar de esta manera es más complejo, requiere más tiempo y posíblemente genere más errores; En contrapartida se dice que se minimiza el tráfico de red y (esto es seguro) vas evitar problemas de bloqueos o de colisiones (Altas y updates).

¿Qué escoger entonces?

Pues depende: Si vas a hacer un sistema para 4 usuarios que hacen 20 altas al día cada uno, creo que perfectamete puedes escoger la primera opción. Si vas a hacer un sistema con 100 usuarios que continuamente van a estar dando de altas registros, cláramente te recomendaría la 2ª.

Son casos extremos, pero es para que me entiendas. No es que una sea la buena y otra la mala. Cada una para lo suyo...

[mamcx]

Empezado por atani123

Otros me dicen que lo mejor es usar TEdit y luego actualizar mediante Update o Insert.

El que te dijo eso seguro ha programado en entornos de MS.

El cuento es que en VB y NET (y básicamente cualquier otro lenguaje tipo rad) los controles datasource son *pésimos* y por años la recomendación es trabajar desligadamente... razon #1, los controles "pegados" eran/son lentisimos, no funcionan muy bien y hay que hacerles cosas manuales así que no ahorran gran cosa - casi siempre solo sirven pa leer pero no pa escribir.

En otros lenguajes donde no hay RAD, solo se trabaja desligado. Osea, es la norma en todos donde no existe un buen diseño de ese tema.

En el caso de Delphi? No veo *ninguna* razón para hacerlo así, con la excepcion de que cierto control no tenga version de BD y simplemente se asignan los valores al control. En Delphi, los controles ligados son rapidos, funcionan bien, sirven pa leer/escibir y se pueden desligar/religar facilmente si se requiere hacer un proceso intensivo (con DisableControls)

[[Lepe]]

...y no olvidemos a nuestro querido ClientDataset que permite trabajar con controles DBEdits, pero realmente estará desligado de la base de datos hasta hacer el ApplyUpdate, así podríamos tener lo mejor de "ambos mundos".

Saludos