Este vai ser "diferente"

[JoséQuintas]

Ainda vou fazer.
Como eu já disse, o sistema ainda mistura DBF e MySQL.
Esta é a rotina atual, usando DBF + MySQL, que agora vai ser só MySQL.

Código: Selecionar todos

   mInfAdic := "PEDIDO " + jppedido->idPedido
   IF ! Empty( jpnotfis->nfLeis )
      FOR nCont = 1 TO Len( Trim( jpnotfis->nfLeis ) ) STEP 7
         mLei := SubStr( jpnotfis->nfLeis, nCont, 6 )
         IF Val( mLei ) != 0
            WITH OBJECT cnMySql
               :cSql := "SELECT * FROM JPDECRETO WHERE IDDECRETO=" + mLei
               :Execute()
               IF ! :Eof()
                  mInfAdic += ";" + :String( "DEDESCR1" ) + " " + :String( "DEDESCR2" ) + " " + ;
                     :String( "DEDESCR3" ) + " " + :String( "DEDESCR4" ) + " " + :String( "DEDESCR5" )
                  mInfAdic := Trim( mInfAdic )
               ENDIF
               :CloseRecordset()
            ENDWITH
         ENDIF
      NEXT
   ENDIF

NFLEIS contém um "linguição", uma lista das leis.
E cada uma das leis precisa ser pesquisada.
Ainda vou fazer testes pra substituir tudo isso por um único comando SQL.

Só que tem um adicional: Na descrição das leis, o texto está dividido em até 5 linhas.
Em MySQL nem precisa disso, tá na hora de modificar, já que esse só existe no MySQL.

Também tem um detalhe adicional:

Hoje está assim: 001002003004

Se eu modificar pra assim: 001,002,003,004

Eu poderia usar essa lista no próprio comando: SELECT * FROM LEIS WHERE LEIS IN ( " + lista + " )"

7 leis x 5 linhas = 35 campos no SELECT do MySQL
Se alterar pra 1 linha, no MySQL sem problemas, 28 campos a menos no SELECT.
E se alterar a vírgula, usar o campo com a lista de leis no comando, sem precisar FOR/NEXT.

Vou pensar nisso.
É por isso que estou convertendo devagar, aproveitando pra facilitar.

Nota:
Aqui não se trata de necessidade do MySQL, ou de qual comando usar.... mas deixar a base de dados mais prática.
Indiretamente tem a ver com o SQL, pois transforma o que seria um comando complicado em algo simples, só por mexer na base de dados.

[JoséQuintas]

Uia, deu certo, tinha esquecido do CONCAT() pra somar strings.

Explicação:
Usei o JPDECRETO 5 vezes, definindo um alias diferente em cada uso
CONCAT() é porque é a soma de strings no mysql.

Considere Concat() como sendo isto no Harbour

Código: Selecionar todos

FUNCTION Concat( a, b)
   RETURN a + b

é que no mysql pra string eu não posso usar A + B, porque isso é só pra números.

[Marcos Kieron]

Procure nao misturar as coisas.
Faça tudo voltado para gerencial e a parte fiscal fica de fora, em outro modulo, isso vai lhe salvar muito trabalho

[JoséQuintas]

Quanto ao AS... considere isso como o ALIAS do DBF:

LEFT JOIN JPDECRETO AS LEI1 ...
LEFT JOIN JPDECRETO AS LEI2 ...

Seria algo como:
USE JPDECRETO ALIAS LEI1
SET RELATION ...
USE JPDECRETO ALIAS LEI2
SET RELATION ...

Pois é... como se fosse um DBASE melhorado
Venho repetindo isso, de comparar com um "DBASE melhorado", porque pode ser o incentivo que falta pra alguns.
Não é uma coisa do outro mundo. é uma coisa conhecida que foi melhorada.

Talvez por isso eu esteja confortável com o SQL, porque lembra muito o DBASE, que foi uma coisa que usei muito, e ainda uso no Harbour.

Procure nao misturar as coisas.
Faça tudo voltado para gerencial e a parte fiscal fica de fora, em outro modulo, isso vai lhe salvar muito trabalho

Não sei exatamente o que isso quer dizer.
No momento meu aplicativo é único... um EXE pra tudo.

[Marcos Kieron]

Isso, um EXE mas o fonte dividido em parte gerencial e fiscal.
A parte gerencial é a parte "util" e a parte fiscal é a "obrigatória" que vai alterar semanalmente (ou não) então para facilitar, coloque toda essa parte separada, alguns até usam modulos externos de empresas especializadas com tecnospeed entre outras.

[JoséQuintas]

Acho que entendi, é pra não precisar atualizar tudo sempre.
Considero muito trabalho pra pouca coisa.

EXE1.png (6.89 KiB) Exibido 3350 vezes

Uso ícones multi-resolução, eles gastam muito espaço.
Mas gosto deles.
Poderia mover pra uma DLL, afinal são 14MB de resource no EXE....
mas nem me preocupo com isso
Atualizar 7MB pela internet é relativamente tranquilo.

[JoséQuintas]

Já postei algumas vezes esse CONCAT().
Precisava adicionar o espaço separador e ia ficar muuuuito grande o comando.
NÃO lembro como pesquisei da outra vez, mas... o CONCAT NÃO é limitado a dois parâmetros.

Assim fica bem melhor.
Só não pode ter parâmetro NULL, senão retorna NULL
Isso significa que eu estava mostrando errado, e vou rever comandos anteriores.

Nota: talvez quando eu testei no começo, tinha algum campo com NULL e não percebi

[JoséQuintas]

Só pra relembrar: não importa o comando, no programa vai ser sempre simples

Código: Selecionar todos

cSql := "o comando acima"
WITH OBJECT oRs := oConexao:Execute( cSql )
   ? :Fields( "IDNOTFIS" ):Value
   ? :Fields( "NFLEIS" ):Value
   ? :Fields( "A" ):Value
   ? :Fields( "B" ):Value
   ? :Fields( "C" ):Value
   ? :Fields( "D" ):Value
   ? :Fields( "E" ):Value
   :Close()
ENDWITH

Repetindo, como sempre:
Reduzir fonte PRG, nada de abrir arquivo, selecionar índice, selecionar área, etc. etc. etc.
Envia o comando, e o servidor devolve pronto.

O que pode dar errado?

NÃO é o Harbour que trabalha
NÃO é nenhuma LIB do Harbour
NÃO é LIB de terceiros
NÃO é o ADO
É o servidor/MySQL

Se o resultado estiver errado, corrige o comando SQL e pronto.

Estou usando ADO, mas ele é só um intermediário, uma classe pra facilitar o uso do MySQL.
Se está tudo funcionando bem, é graças ao MySQL, porque ele é quem faz tudo.

Lembrem-se disso quando forem testar ADO, SQLMIX, hbMySQL ou qualquer outra forma de conexão.

O servidor faz o trabalho pesado, e tem que ser rápido.
Se ficar lento... pode ser comando errado, ou pode ser o programa intermediário que está atrapalhando.

[Marcos Kieron]

SELECT CONCAT( "Segue ", "exemplo ", "de ", "concat" ) AS Exemplo;