Sim, entendo, mas também entendo que diversas coisas poderiam ser implementadas no modelo de OOP do VFP, mas ainda não foram.

Bom, aproveito a oportunidade para pedir que vc relacione alguns itens e se possivel demonstre a vantagem que isto ira trazer p/ o desenvolvedor VFP...
Afinal nada como alguns modelos que o pessoal possa visualizar e entender p/ que possa solicitar.

O que eu mais desejo, e acredito que a maioria tambem é um relatorio OO, mas isto já se esta solicitando a séculos p/ a MS...
Agora faltam melhorias no CA p/ facilitar o uso da ferramenta p/ agilizar o desenvolvimento.

Nem me fala: eu ODEIO T-SQL. Cada vez que tenho que escrever algo em T-SQL e me lembro como é fácil fazer a mesma coisa no VFP, fico puto da vida. Mas, atenção: no Yukon (próxima versão do SQL Server), ele trabalhará não só com T-SQL, mas também com linguagens .NET. Ou seja: será possível escrever procedimentos que na verdade serão métodos em objetos, então poderemos escrever coisas complexas com linguagens decentes. Aí está outro motivo para o desenvolvedor VFP ficar antenado com o .NET, afinal é mais fácil aprender C# ou VB.NET e ADO.NET (pois já estamos >acostumados com OOP), do que aprender o T-SQL. ;)

Olha, eu resolvi parte do meu problema com T-SQL, pois gerei um construtor de Stored Procedures via VFP, desta forma 85% ou mais de todo o código que escrevo no SQL esta resolvido, só tenho de escrever código especifico p/ tratar de alguns casos.
Quanto a nova versão do SQL, entendo que o funcionamento com o .NET será através de DLL's (pelo menos é isto que entendi), se for este o caso, não entendo pq. não poderia usar o VFP p/ fazer isto pois se tratar de uma linguagem voltada a dados, o que é demonstrado pelos comandos e funções que a linguagem tem, e tb. é possivel se criar Dll's que o SQL Server poderia chamar.
Isto é um desejo particular meu, pois facilitaria muito criar app. cliente/servidor.

[],s

Peter