ADO, Access y SQL
 

Hola amigos...
Para seguir complicandome la vida, ahora decidi incursionar en ADO y que mejor que para complicarme del todo, que trabajar contra una DB del tipo MS_Access.:rolleyes:

Ahora bien, al diseñar las tablas:
Con ADO, ¿como se establecen campos Lockup y relaciones Maestro/Detalle o solamente se hacen consultas SQL?

Al diseñar las consultas:
Desde el entorno de MS-Access (que utilizo para crear las tablas) se puede almacenar dentro del mismo archivo MDB consultas SQL y otras hechas con relaciones entre campos.
¿Es posible recuperarlas y ejecutarlas desde Delphi?
¿Cómo se hace?

Si, si, si...

Las relaciones maestro/detalle puedes manejarla desde MS Access, declarando relaciones entre tablas. Access maneja, hasta donde recuerdo, la integridad referencial, y creo que actualizaciones y borrados en cascada.

Con respecto a lo de las consultas, puedes construirte vistas de tablas, y reutilizarlas justo como si fuesen tablas comunes.

Hola,

tal como yo lo veo un Master/Detail en Delphi no hace lo mismo que las relaciones de Access...

Las relaciones de access se encargan de mantener la integridad referencial, es decir, no permiten que exista una clave ajena que no exista en la tabla relacionada. El borrado en cascada es una manera de asegurar esto.

Sin embargo, lo que hacen las relaciones maestro/detalle de Delphi es filtrar del detalle todos los registros relacionados con el registro actual de la tabla maestra, independientemente de que haya una restricción de integridad referencial entre las dos tablas.

Con los lookup pasa lo mismo, si quieres puedes hacer un join entre dos tablas access, pero los lookups de Delphi son más flexibles, ya que te permiten ir a buscar un campo a un DataSet que no tiene porqué pertenecer a esa misma base de datos. El que sea mejor un lookup o un join dependerá de cada caso, aunque la mayoría de veces un lookup es más eficaz dado que está en el lado de la BD, evitándonos "código" adicional Delphi.

Por cierto, las consultas SQL que tengas definidas en Access te aparecerán desde Delphi como si fueran tablas. De hecho, puedes considerarlas como vistas.

Espero haberme explicado.

Saludos.

Ok, gracias.
O sea, segun lo que me explican Hector y MarcSC, si defino una sentencia SQL y la guardo con el nombre PIRULO...

¿la cargo con un TADODataSet desde mi aplicacion como si fuera una Tabla de nombre PIRULO o como un string SQL?

¿Luego puedo linkear ese TADODataSet a un TDataSource y este a un DBGrid, mostrando los datos resultantes?

¿Es más ágil que la consulta esté almacenada en la propia MDB o es más apropiado armar la sentencia desde mi DataModule con un componente TADOQuery?

Pues en teoría puedes hacer las dos cosas, tener la Tabla PIRULO o hacer un Select from PIRULO ;)

Bueno, puede ser un TADOQuery, TADOTable o TADODataSet, aunque en teoría los dos primeros son los más utilizados.

Pues yo diría que igual de ágil, quizás un poco más si lo haces directamente desde el ADOQuery, pero no creo que lo notes. Como te comentaba yo a las consultas de Access les veo más el sentido de Vistas. Por ejemplo, si tu tienes una tabla de Clientes a lo mejor te interesa tener una vista en la BD de Clientes Morosos para luego hacer queries sobre esta vista. Por ejemplo, si tienes todo un módulo de consultas sobre morosos posiblemente te interesará tener la vista definida, mientras que si tu aplicación solo tiene que dar una simple relación de morosos con un simple Query te sobra.

Saludos.

Gracias MarcSC...

Preguntaba lo de dónde hacer el Query porque algunos suponen que tenerlo del lado del "motor", en este caso la DB, lo hace más rápido.

Por otro lado, ¿vos me querés decir que conviene armar las vistas en el Access, guardarlas con un nombre y llamarlas como si estuviera llamando una tabla?...

El componente TADODataSet opera indistinamente con consultas SQL como con la tabla directamente, segun lo aportado a la propiedad CommandType. Si esta es cmSQL (o sea que utilizaemos un comando SQL) tambien se usa la propiedad CommandText para poner la sentencia.

¿Alguien sabe si en runtime puedo asignar estas propiedades indistintamente y utilizarlas según sea necesario aunque ya tenga asignadas otras en tiempo de diseño... digo, si yo establezco que trabaje con una tabla XXX y en runtime le cambio la propiedad CommandType para que trabaje con una sentencia SQL no se cuelga?
(Que despiole hice, no?)

El problema en este caso es que Access no es un motor de base de datos cliente servidor y todas las consultas que realices, estén guardadas o las crees desde Delphi, van a ejecutarse desde el cliente, es decir que el tiempo de respuesta va a depender de la red de comunicación y de la capacidad del cliente.

Cuando realizas un Query todos los datos viajan por la red y el cliente es quien hace los filtros de estos. Que no es el caso de una Base de Datos C/S como Interbase u otra.

Ademas de que, en servidores de bases de datos, se toma un tiempo adicional el 'compilar' el mandato sql enviado por el cliente para ser ejecutado, lo cual incurre en tiempo adicional. Es una de las razones por las cuales recomiendan utilizar Stored Procedures (las vistas creo que trabajan igual), ya que al ser guardados en el servidor, estan 'pre-compilados'

Hablando de Roma... ¿saben Uds. como se utiliza el componente TADOStoreProc en estos casos?

Por lo que tengo entendido, y creo que ya se ha hablado en el foro, desde fuera del Access no se puede acceder a las funciones y procedimientos de este, esto es entendible puesto que no existe un Servidor de Access... como ya se ha hablado en este hilo.

Saludos!