Inicialização de telas com tabelas SQL.

[Mario Mesquita]

Boa noite a todos.

Pessoal, estou estudando o uso de tabelas SQL no lugar dos nossos amados DBFs. Estou usando MySql com ADO.

Gostaria de saber de vocês qual a melhor técnica na construção de telas que pegam dados de várias tabelas e colocam em objetos como Grids, ComboBox,
etc. ao inicializar alguma tela que leiam algumas tabelas ao carregar.

Hoje eu abro e ligo aos DBFs quase diretamente, mas no caso de SQL, acho que teria que fazer alguns Selects para preencher os objetos com os recordsets resultantes.

Imaginem uma tela de venda, onde se pegam os produtos, o(s) cliente(s), o(s) vendedor(es), tudo pré cadastrado. Ao abrir a tela, disponibilizar essas
informações nos objetos para o operador selecionar e no fim tudo ser gravado nas tabelas de venda.

Aliás, as críticas de ter ou não certos dados, que fazemos busca com o SEEK nos DBFs, como seria? Testar se voltou algo no Recordset?

Ao gravar a operação, fazer verificações para não ter violações tipo: não duplicar chaves primárias, ou valor NULL em campos NOT NULL?

Porquê vi que dá erro de execução ao fazer essas operações indevidas.

Fazendo isso em DBF a vida toda, sempre foi tranquilo, mas agora como ainda estou adquirindo experiência, gostaria de saber qual a melhor prática.

Desde já, agradeço as dicas dos colegas.

Saudações,
Mario.

[JoséQuintas]

Vai de cada um.
Eu ainda estou no primeiro ano de uso do MySQL pra valer.
Ainda uso um misto de trazer muito ou trazer partes, inclusive em relatórios.
O demorado, se é que pode ser chamado de demorado, é a conexão inicial.

Procurei adaptar o uso de MySQL aos meus fontes, e também fui criando funções de apoio, pra reduzir fonte.
Um fonte relativamente simples, que contém coisa inútil, já que está preparado pra várias telas mas só usa uma.

Código: Selecionar todos

METHOD TelaDados( lEdit ) CLASS JPTABORIGEMClass

   LOCAL GetList := {}, mORIGEMNome, mORIGEMInfInc, mORIGEMInfAlt, cidORIGEM
   LOCAL cnSQL := ADOClass():New( AppConexao() )

   cIdORIGEM := ::axKeyValue[ 1 ]
   WITH OBJECT cnSQL
      :cSQL := "SELECT * FROM JPTABORIGEM WHERE IDORIGEM = " + StringSQL( cIdORIGEM )
      :Execute()
      mORIGEMNome := :String( "ORIGEMNOME", 80 )
      mORIGEMInfInc := :String( "ORIGEMINFINC", 80 )
      mORIGEMInfAlt := :String( "ORIGEMINFALT", 80 )
      :CloseRecordset()
   ENDWITH

   hb_Default( @lEdit, .F. )
   DO WHILE .T.
      ::ShowTabs()
      DO CASE
      CASE ::nNumTab == 1
         @ Row()+1, 1 SAY "Código.............:" GET cIdORIGEM PICTURE "9" WHEN .F.
         @ Row()+2, 1 SAY "Descrição..........:" GET mORIGEMNome PICTURE "@K!"
         @ Row()+2, 1 SAY "Inf.Inclusão.......:" GET mORIGEMInfInc WHEN .F.
         @ Row()+1, 1 SAY "Inf.Alteração......:" GET mORIGEMInfAlt WHEN .F.
      ENDCASE
      //SetPaintGetList( GetList )
      IF lEdit
         Mensagem( "Digite campos, F9 Pesquisa, ESC Sai" )
         READ
         Mensagem()
         ::nNumTab += 1
      ELSE
         CLEAR GETS
         EXIT
      ENDIF
      IF LastKey() == K_ESC
         EXIT
      ENDIF
      IF ::nNumTab == Len( ::acTabName ) + 1
         EXIT
      ENDIF
   ENDDO
   IF LastKey() == K_ESC
      RETURN NIL
   ENDIF
   IF lEdit
      WITH OBJECT cnSQL
         :QueryCreate()
         :QueryAdd( "ORIGEMNOME", mORIGEMNome )
         IF ::cOpc == "I"
            :QueryAdd( "ORIGEMINFINC", LogInfo() )
            :QueryAdd( "IDORIGEM", cIdORIGEM )
            :QueryExecuteInsert( "JPTABORIGEM" )
         ELSE
            :QueryAdd( "ORIGEMINFALT", LogInfo() )
            :QueryExecuteUpdate( "JPTABORIGEM", "IDORIGEM= " + StringSQL( cIdORIGEM ) )
         ENDIF
      ENDWITH
      ::nNumTab := 1
   ENDIF

   RETURN NIL

Essa tela atende inclusão, alteração, consulta e exclusão.

[JoséQuintas]

E quanto ao grid.... com tbrowse vai bem, aliado às minhas rotinas.

Código: Selecionar todos

METHOD GridSelection() CLASS JPTABORIGEMClass

   LOCAL oTBrowse
   LOCAL cnSQL := ADOClass():New( AppConexao() )

   WITH OBJECT cnSQL
      :cSQL := "SELECT * FROM JPTABORIGEM ORDER BY ORIGEMNOME"
      :Execute()
      oTBrowse := { ;
         { "CODIGO", { || :String( "IDORIGEM", 1 ) } }, ;
         { "NOME",   { || :String( "ORIGEMNOME", 30 ) } } }
      BrowseADO( cnSQL, oTBrowse, "ORIGEMNOME", { || :String( "IDORIGEM", 1 ) } )
      :CloseRecordset()
   ENDWITH

   RETURN NIL

O método :String( "campo", nTamanho ) acaba definindo a largura das colunas, sem depender de informação do banco de dados.
Apesar de não ter a rotina de browse aqui, dá uma idéia, porque as colunas são no formato do tbrowse.

[JoséQuintas]

Lembrando que o ponto de partida para o browse foi uma rotina postada pelo alxsts.

Começar pelo browse pode ser o melhor negócio, foi depois dele que finalmente migrei.

[JoséQuintas]

Nesta outra, já busco o que vai ser usado no tbrowse inicial, só pra mostrar a lista.

[JoséQuintas]

Só um comentário adicional:

O pessoal esquece, mas dá pra usar o GET como SAY.

Código: Selecionar todos

@ 1, 0 SAY "dddd" GET y
CLEAR GETS

Dá pra usar assim, ou com WHEN .F.
É isso que permite usar a mesma tela pra digitação ou só pra mostrar.
Isso economiza telas.

Ou, digamos que seria igual GUI, deixando os controles de edição desabilitados pra edição.

[Itamar M. Lins Jr.]

Olá!

Imaginem uma tela de venda, onde se pegam os produtos, o(s) cliente(s), o(s) vendedor(es), tudo pré cadastrado. Ao abrir a tela, disponibilizar essas
informações nos objetos para o operador selecionar e no fim tudo ser gravado nas tabelas de venda.

Pois é!
E ai ? vai usar JSON, Array, ADO ou DBF... ?
Eu estou aqui pensando, que precisa armazenar todos os produtos em algum lugar e DEPOIS de confirmada a venda, passar para outra tabela.
Pode criar e gravar a tabela com os produtos escolhidos pelo cliente dentro do MariaDB ou em algum DBF local.
Vai usar ADO no caso de criar a tabela temporária ? Pode também mas se DBF faz a mesma coisa ?
Com SQLMIX pode abrir as tabelas e usar dbseek(), etc não vai mudar essa parte.
Agora vc está vendo a diferença do SQLMIX para o ADO.
Pq se vc grava por exemplo usando os recursos do Harbour dbcreate(mem:meu.dbf...) vc joga tudo nele na RAM ou pode salvar no disco o DBF... Só se preocupando em aprender SQL que é o avanço real, ADO não é avanço é apenas uma PONTE para o MariaDB.

Estou escrevendo pq, ainda não resolvi isso na cabeça, já resolvi algumas coisas.
Browse, GET, mas a parte PEDIDOS, que abre praticamente, todas as principais tabelas do sistema. Faço com ADO ou com SQLMIX ?
Isso eu tenho funcionando super rápido com tabelas enormes, 50 mil itens no estoque, mais de 700 mil itens nas entradas... com DBF e LetoDb.
E se for trocar é para melhorar, não é para ficar pior nem igual.

Ai precisamos abrir o estoque vai criar o RS_1(puxa tudo ou apenas 1000 itens ?), depois abrir clientes criar RS_2(idem ou apenas os primeiros 1000 clientes ?)
Vendedores são sempre poucos, depois o caixa, e outros menores, formas de pgto(finalizadoras)...
Pq no DBF usando LetoDB eu nem me preocupo com isso.
Uma coisa é mostrar as maravilhas do SQL quando usamos para relatório, outra e saber adequar a realidade e que funciona muito bem do DBF, nessa parte de pedidos, orçamentos, etc. mover isso para o MariaDB.
Depois de gravado tudo em um arquivo, pois pode faltar energia, cair conexão, etc...
Dou um:

Código: Selecionar todos

Begin Transaction... no pedido. Pq requisições em SQL falham também
DO WHILE .not. EOF() 
cSQL := "insert into..."
dbskip()
ENDDO 

E apago o DBF temporário.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Estou escrevendo pq, ainda não resolvi isso na cabeça, já resolvi algumas coisas.
Browse, GET, mas a parte PEDIDOS, que abre praticamente, todas as principais tabelas do sistema. Faço com ADO ou com SQLMIX ?
Isso eu tenho funcionando super rápido com tabelas enormes, 50 mil itens no estoque, mais de 700 mil itens nas entradas... com DBF e LetoDb.
E se for trocar é para melhorar, não é para ficar pior nem igual.

No browse, talvez uma coisa que acostumamos é mostrar tudo.
Mas porque mostrar tudo?
Porque o usuário iria "fuçar" nas informações?
O usuário deve ter alguma referência de pesquisa, então o browse começaria depois de alguma referência ao que interessa, e isso já reduz o browse.

Ai precisamos abrir o estoque vai criar o RS_1(puxa tudo ou apenas 1000 itens ?), depois abrir clientes criar RS_2(idem ou apenas os primeiros 1000 clientes ?)
Vendedores são sempre poucos, depois o caixa, e outros menores, formas de pgto(finalizadoras)...
Pq no DBF usando LetoDB eu nem me preocupo com isso.

Meus browses já eram em rotinas separadas, então eles tem seu próprio recordset e retornam o código.
No caso de validações, também já eram rotinas separadas, e tem seu próprio recordset.
Ou seja, é tudo feito sem nada aberto a não ser a conexão.
Se acabar a luz, cair conexão.... não tem nada aberto.
Vai perder o que estava em digitação e nada mais.

Numa digitação no estoque, vai validando tudo, só com a conexão aberta, sem recordset.
Quando tudo ok, grava as atualizações necessárias e pronto, também sem recordset pra comandos.
Exatamente como o SQLMIX faz, eu acho.

Mas tem o recordset isolado do servidor, e tem o recordset vinculado ao servidor, não sei qual dos dois estilos o SQLMIX usa.
A diferença é um trazer tudo, e o outro depender do servidor.
E tem outros também, mas eu fui direto no que trás tudo, assim fica totalmente sem vínculo.
TUDO não quer dizer tudo do banco ou da tabela, e sim a parte que interessa.

[JoséQuintas]

Código: Selecionar todos

METHOD GridSelection() CLASS JPTABORIGEMClass

   LOCAL oTBrowse
   LOCAL cnSQL := ADOClass():New( AppConexao() )

   WITH OBJECT cnSQL
      :cSQL := "SELECT * FROM JPTABORIGEM ORDER BY ORIGEMNOME"
      :Execute()
      oTBrowse := { ;
         { "CODIGO", { || :String( "IDORIGEM", 1 ) } }, ;
         { "NOME",   { || :String( "ORIGEMNOME", 30 ) } } }
      BrowseADO( cnSQL, oTBrowse, "ORIGEMNOME", { || :String( "IDORIGEM", 1 ) } )
      :CloseRecordset()
   ENDWITH

   RETURN NIL

Voltando nesse fonte.
a classe ADOClass() é uma mistura de conexão com recordset, mas usa a conexão default.

Código: Selecionar todos

   LOCAL cnSQL := ADOClass():New( AppConexao() )

aqui cria o comando SQL e trás o resultado da consulta
como é a tabela de origem da mercadoria, é minúscula, então nem me preocupei em reduzir a consulta.

Código: Selecionar todos

      :cSQL := "SELECT * FROM JPTABORIGEM ORDER BY ORIGEMNOME"
      :Execute()

Uma vez feito o browse, e escolhido o código, a informaçào se torna inútil, então fecha o Recordset, não a conexão.

Código: Selecionar todos

      oTBrowse := { ;
         { "CODIGO", { || :String( "IDORIGEM", 1 ) } }, ;
         { "NOME",   { || :String( "ORIGEMNOME", 30 ) } } }
      BrowseADO( cnSQL, oTBrowse, "ORIGEMNOME", { || :String( "IDORIGEM", 1 ) } )
      :CloseRecordset()

E prossegue no módulo que chamou a rotina, sem nada que existia nela, exceto o código selecionado.

[JoséQuintas]

Código: Selecionar todos

   @ Row()+1, 1  SAY "Portador.........:" GET nIdPortador PICTURE "@K 999999" VALID JPTABFINPORClass():Valida( @nIdPortador )
   @ Row()+1, 1  SAY "Operação.........:" GET nIdOperacao PICTURE "@K 999999" VALID JPTABFINOPEClass():Valida( @nIdOperacao )

Aqui o que comentei: tenho rotinas de validação.
O SEEK que faria no DBF, foi substituído pelo SELECT, mas o fonte de digitação nem sabe o que a validação faz.
Cada validação tem seu recordset com seu comando SELECT.
É ruim? não. Se vai validar código de cliente ... é sempre igual, então uma rotina só pra código de cliente, atendendo o aplicativo inteiro.
E o mesmo pra cada tabela.

A tela de digitaçào acaba se limitando ao pedido/produtos, não precisa encher de comandos SQL, basta chamar as rotinas de validação.

Eu já fazia isso com DBF, então com SQL não teve mudança significativa no funcionamento geral.

A não ser..... o fato do DBF permanecer aberto, onde eu aproveitava isso pra trabalhar com o registro atual.
Agora é tudo na base do código/id de registro.
É uma variável substituindo o que antes era um campo, aonde necessário.

[JoséQuintas]

Ainda dentro desse conjunto....

Se SQLMIX é por comando SQL, e uso ADO por comando SQL, então é tudo igual.

A única diferença é que você prefere o retorno usado igual DBF, e eu prefiro igual ADO.
Isso só faz diferença em consultas, e não em gravação.

Se vai ser usado array, dbf, ou recordset ADO, tanto faz.
Trata-se apenas da classe/função que vai acessar o retorno.

Se vai acessar por cliente->codigo ou por rs:Fields( "CODIGO" ):Value, não vejo o quão diferente isso seja, a não ser aproveitar fonte e/ou gosto pessoal.

[Mario Mesquita]

Boa tarde a todos.

Eita, valeu pelas dicas, vou ter que ler com calma pra entender os detalhes mas acho que dá pra pegar o contexto.

Então, Itamar, optei pelo ADO no trato do MySql. Já tinha usado a LibMySql e gostei mas entendi que saber usar o ADO ajuda ao usar outras ferramentas que
transacionam com o Windows. Imagino que o SQLMix tb facilite em se tratando de Harbour, como a LibMySql, que devolve a busca em forma de vetor.

No fim, parece que todos os caminhos tem prós e contras, é questão de se adaptar. Aliás, essa LibMySql pode ser usada nos clientes com perfomance normal, né?
Não é apenas para estudo e testes, é pra uso real, procede?
Pois ela pode servir em algumas tarefas, e é sempre um coringa caso aconteça algo, sei lá...

Vejam, como já falei, para o porte do meu trabalho o DBF resolve fácil e gosto muito de usa-lo, mas como ele é restrito ao mundo xbase, decidi usar pra aprender novas coisas, que não vão usar DBFs. Não fosse isso, ficava no DBF mesmo, acho muito satisfatório.

Ainda vou ter muitas dúvidas, mas acho que vou pegar e fazer até me divertindo, sempre bom aprender coisa nova.

Grato a vocês pelas dicas,
Mario.

[Itamar M. Lins Jr.]

Olá!
Não vou trazer 50 mil registros. Vou pegar apenas a parte que interessa ao vendedor.
[Código][Descrição][Preço][...] Tem mais uns 5 campos. Vou pegar menos de 100 itens que é o que cabe no browse.
Nem irei criar um array/etc com isso. Eu já vi como é a pesquisa incremental a cada letra/numero/uso do leitor/ pressionada o sistema manda uma "QUERY" para o SGBD.
Ainda não vi isso aqui no forum, tenho aqui no VB e na internet, para cada letra digitada o sistema faz um select.
Não tem botão, por exemplo o vendedor digita alguma coisa e tecla enter. O enter ele só tecla quando acha. Não tira a mão do teclado para pressionar o botão do mouse.
Um ComboBox da Hwgui(Igual no HTML) por exemplo, faz pesquisa, não preciso me preocupar com isso. O problema é quando a pesquisa "letra a letra" é em uma base muito grande, não vou subir a base toda, mesmo que seja apenas código e descrição.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

O problema é quando a pesquisa "letra a letra" é em uma base muito grande, não vou subir a base toda, mesmo que seja apenas código e descrição.

Na consulta letra a letra, digamos que seja 1 segundo ou até um pouco menos, se juntar o tempo de navegação ou de digitação, pode dar 1 minuto usando servidor/rede.
Se trouxer tudo, pode ser 1 ou 2 segundos, e fim, pode navegar à vontade, o tempo que for, e não precisa servidor/rede.
A comunicação entre MySQL pode usar a velocidade máxima da rede, usa e já libera toda rede.
Vários pequenos blocos não vão aproveitar o máximo da rede, mas vão atrapalhar, e é justamente essa a diferença entre DBF e MySQL.

Mas pensei em outra coisa:
Temos aqui uma boa diferença entre Windows e Linux.
No Windows, a estação busca do servidor, já no Linux a estação é o próprio servidor.
Isto pode indicar que as solução de um não é a mesma solução do outro.
E também diferente se rodando num site.

[Itamar M. Lins Jr.]

Olá!

No Windows, a estação busca do servidor, já no Linux a estação é o próprio servidor.

Não sei de onde tirou isso. A cada hora é uma novidade.
Quer dizer que se usar 2 ou mais maquinas Linux com 1 servidor, vai buscar dela mesma... Essa foi boa, telepatia na informática.
Quando uso meu notebook(win) com Mysql instalado busco do espaço sideral...

Saudações,
Itamar M. Lins Jr.