Depois disso, trata-se apenas de não usar mais o DBF.
Se alterar só o arquivo de clientes, não vai ser suficiente pra transformar um relatório de notas fiscais por cliente totalmente pra MySQL, mas talvez possa alterar o relatório de clientes.
Se alterar só o arquivo de notas fiscais, idem, mas talvez possa pelo menos buscar as notas fiscais, e pesquisar os clientes via DBF.
Se alterar os dois, pode fazer totalmente em MySQL.
Justamente por isso mudei minha conversão:
Comecei alterando um arquivo por vez pra MySQL, mas notei que se fossem vários, teria mais vantagem.
Neste ponto dá pra comparar SQLMIX com ADO, ou esse esquema de alteração:
Vantagem do SQLMIX sobre ADO: não alterar o fonte na parte de leitura, mas precisa alterar gravação igual ADO, pra comandos SQL.
Vantagem do SQL: consultas trazendo somente o que interessa, o que só é obtido com alteração de fonte, caso contrário fica pior do que com DBF.
Conclusão: a vantagem do SQLMIX é.... aproveitar fonte que vai ser jogado fora, ganhar tempo de conversão deixando mais lento do que deveria ser.
E o pior: pode dar a falsa impressão de que SQL é demorado, porque o fonte não foi feito pra SQL e sim pra DBF.
Por outro lado, é lógico, depende do programador.
Esse mesmo esquema que usei pra ADO poderia ser usado pra SQLMIX.
Do mesmo jeito que estou alterando relatórios pra tirar proveito do MySQL usando ADO, também poderia ser usado no SQLMIX.
Acho que o maior problema do SQLMIX NÃO é o SQLMIX, mas o fato dele dar a impressão ao programador que vai continuar trabalhando igual DBF.
SQL é relativamente simples, mas o programador precisa entender que SQL é SQL, e DBF é DBF.
E ficar usando SQL igual DBF não é uma boa maneira do programador entender isso.
Não sei se seria exagero dizer o seguinte:
SQLMIX é ótimo, pra quem já está acostumado com SQL, e não pra principiante que está começando a entrar no mundo SQL.
Quem já está acostumado com SQL, sabe muito bem a diferença, mas quem está começando.... vai entender cada vez menos.
o ADO deixa mais claro isso, mas nem sei se mesmo assim o pessoal entendeu.
Basicamente são duas variáveis:
uma variável é a conexão, é o elo de ligação entre o programa e o servidor
oConexao := win_OleCreateObject( "ADODB.Connection" )
Outra variável é a resposta do servidor, contendo qualquer coisa.
É enviar o comando e obtém-se a resposta em uma variável.
oTemporario := oConexao:Execute( "comando sql" )
Podemos fazer consultas diferentes, em variáveis diferentes, mas isso é uma variável contendo a resposta do servidor em formato ADO.
É o Windows que faz isso, talvez seja array, talvez seja arquivo temporário, não faço idéia, apenas é fazer uso disso.
Com certeza o SQLMIX faz algo parecido, mas na maior parte do tempo é um SELECT *, trás tudo, quando nem precisamos de tudo.
Mas é lógico, como eu disse, depende do programador ENTENDER do que se trata SQL, e impedir que isso seja feito.
O fato do SQLMIX trazer em formato DBF, não significa que isso virou DBF.
Até mesmo hbmysql... qual a vantagem de trazer o processamento ao aplicativo, se o Windows faz isso sozinho e mais rápido?
De qualquer forma, só existe ADO no WINDOWS.
Mas nada impede do programador usar ADO pra ENTENDER SQL, e só depois adotar o SQLMIX da forma correta, ou pra usar no Linux, ou pra permitir usar os browses de libs gráficas que só atendem DBF ou Array.
Na prática o ADO é igual uma RDD, com muito mais recursos do que comandos SQL, mas.... podem entrar particularidades do ADO.
Como comparação:
O jeito que eu mostro ADO aqui no fórum, seria o mesmo do que usar SQLMIX apenas com o Execute().
E se o ADO morrer?
- executar comandos
- executar comandos trazendo retorno
Se uma LIB fizer isso, o que todas fazem, ninguém está nem preso ao ADO e nem ao Windows, pode trocar quando quiser.