Pero tal como lo esbozas no parece tener muchas posibilidades.
De entrada, el método Leer devuelve vDatos.DataSource pero a esta propiedad del objeto ADOQuery nunca le asignas nada, además de que dicha ppropiedad es para el paso de parámetros al Query. Quizá quisiste devolver el DataSource que creaste, pero, por un lado, tal objeto creado no apunta, aparentemente, a ningún DataSet y tampoco está declarado en el método. ¿De dónde sale?
Por otro lado, si lo que quieres es devolver el DataSet que creas al vuelo, ya sea directamente o através de un DataSource, entonces no puedes destruir el objeto en el mismo método, porque entonces la rutina que lo reciba obtendrá un objeto muerto.
Tendrías que dejar que sea el receptor quien se encargue de destruir al DataSet, lo cual es propenso a errores pues le dejas una responsabilidad que probablemente no deba tener.
Alguna vez hice algo parecido, basándome en código de otros, en donde lo que devuelves, no es un DataSet sino una
interfaz que contiene una DataSet. Dicha interfaz estaba implementada por un descendiente de TInterfacedObject y lo que logras con eso es un recolector de basura. Esto es, el objeto se destruye automáticamente una vez que se pierden todas las referencias a él (es la idea, los detalles no los recuerdo bien ahora).
De todas formas, no es algo tampoco que vayas a hacer en un rato.
No sé yo si estás tomando el camino adecuado dada la premura de tiempo.
Tú puedes hacer aplicaciones con varias capas usando una triada
Código:
DataSet <---> DataSetProvider <---> ClientDataSet
exponiendo únicamente el ClientDataSet al cliente. Esto te permite cambiar con relativa facilidad la capa del DataSet. En una aplicación real a tres capas, el DataSet viviría en un RemoteDataModule, pero por lo mientras lo puedes colocar en un DataModule normal. Creo que alguien (¿Al González?) llamó a esto una aplicación a dos capas y media
// Saludos