FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#4
|
||||
|
||||
Cita:
Cita:
Pablo: Yo utilizo un estilo de nombres similar para los campos llaves, pero eso puede ocasionar el problema que explicas al usar conjuntos de datos anidados. El problema tiene que ver con el método TDataPacketWriter.AddFieldLinks de la unidad Provider, el cual se encarga de establecer la relación de campos maestro-detalle a nivel del "paquete" de datos. Pero el "culpable" en sí no es él, sino el método GetDetailLinkFields de la mayoría de los componentes de acceso a consultas SQL, como por ejemplo TCustomSQLDataSet:
(por cierto, ¿qué componentes estás usando del lado del proveedor?) De una forma por demás simple, todos los componentes query nativos asumen que los parámetros de relación (campos maestros) llevan el mismo nombre que los campos detalles a los cuales se aplica el Where. Por ello ocurre la incorrecta asignación que reportas, la cual no puede ser solucionada como lo intentaste porque el campo ID detalle ya viene incorrectamente "marcado" desde el proveedor como campo de relación. Este problema ha sido reportado al fabricante desde el año 2002, sin que éste haya proporcionado aún una solución nativa (puede que Borland y Embarcadero estén muy apegadas al redundante estilo Customer.IDCustomer y no estimen gran cosa al elegante Customer.ID ). No obstante, en su sitio Web puedes encontrar dos temas que hablan del mismo problema, y al final de los cuales se dejan entrever posibles soluciones: https://forums.codegear.com/message.jspa?messageID=2593 http://qc.embarcadero.com/wc/qcmain.aspx?d=1488 La primera es añadir una columna con alias a la consulta maestra:
Esto ya lo probé y funciona perfectamente. Sólo recuerda quitar las banderas pfInUpdate y pfInWhere del nuevo objeto campo, y asignarle el mismo valor que le des al campo ID. La segunda sería redefinir el método virtual GetDetailLinkFields (que para eso son los métodos virtuales), creando una clase derivada de la que estés utilizando. Es un poco más elaborada, pues habría qué pensar qué código escribir en el nuevo método para hacerlo funcionar como queremos (las ideas que se proponen en el segundo enlace no me agradan mucho que digamos). Ambas soluciones te evitarán tener que renombrar los campos, a lo cual José se vio obligado desafortunadamente (a diferencia de lo que sería un framework, una biblioteca general no debe imponer estilos de nombres). Diviso una tercera solución que sería llamar con ciertos parámetros al método AddOptParameter de la interfaz DSBase maestra, pero no lo he estudiado del todo. Espero haber ayudado de alguna manera. No dejes de retroalimentar este hilo. Al González. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
ClientDataSets y Firebird | Walterdf | Conexión con bases de datos | 19 | 27-08-2010 20:41:31 |
Capturar errores - ClientDataSets | rochi | Providers | 3 | 22-11-2008 00:05:17 |
ClientDataSets con parámetros, no funciona la consulta | rochi | Providers | 3 | 10-10-2008 20:47:24 |
ClientDataSets- Personalizar errores | rochi | Conexión con bases de datos | 0 | 03-05-2008 06:47:52 |
Clientdatasets anidados con ADO | Johnny Q | Conexión con bases de datos | 4 | 03-11-2005 02:53:25 |
|