Clipper On Line • Ver Tópico - O ADO continua indo
Página 1 de 1

O ADO continua indo

MensagemEnviado: 10 Fev 2016 20:06
por JoséQuintas
Está acabando a parte fácil, depois ainda não sei como vou fazer.

Aqui um trecho da rotina executada automaticamente na carga do sistema, mexendo com estruturas do MySQL:

FUNCTION AlteradoEntreVersoes()

   LOCAL cnMySql := ADOClass():New( AppCnMySqlLocal() )
   LOCAL aFileList, oEachFile

   SayScroll( "Campo JPRECIBO.RESTATUS" )
   IF .NOT. cnMySql:FieldExists( "RESTATUS", "JPRECIBO" )
      cnMySql:ExecuteCmd( "ALTER TABLE JPRECIBO ADD COLUMN RESTATUS VARCHAR(1) NULL DEFAULT ''" )
   ENDIF
   SayScroll( "Renomeando BAIRRO pra HLBAIRRO" )
   IF cnMySql:TableExists( "BAIRRO" )
      IF cnMySql:TableExists( "HLBAIRRO" )
         WriteErrorLog( "Conferir sobre MySQL.BAIRRO e MySQL.HLBAIRRO" )
      ELSE
         cnMySql:ExecuteCmd( "RENAME TABLE BAIRRO TO HLBAIRRO" )
      ENDIF
   ENDIF
   ...

O ADO continua indo

MensagemEnviado: 10 Fev 2016 20:22
por JoséQuintas
E aqui um trecho de outra rotina que vai ser obrigatória a execução em primeiro lugar antes de qualquer outra coisa.

FUNCTION HLSalvaMySQL()

   LOCAL nAtual, nTotal, cTmpFile, cnMySql := ADOClass():New( AppcnMySqlLocal() )

   IF .NOT. MsgYesNo( "Já reindexou tudo? Confirma transferência?" )
      RETURN NIL
   ENDIF

   // RemoveAcessoDesativado()

   SayScroll( "hlcofre.dbf" )
   IF .NOT. File( "HLCOFRE.DBF" )
      WriteErrorLog( "HLCOFRE.DBF não existe. Retirar rotina" )
   ELSE
      CopyDbfToMySql( "HLCOFRE", .T. )
      fRename( "HLCOFRE.DBF", "HLCOFRE.BAK" )
   ENDIF

   SayScroll( "hlcaixa.dbf" )
   IF .NOT. File( "HLCAIXA.DBF" )
      WriteErrorLog( "HLCAIXA.DBF não existe. Retirar rotina" )
   ELSE
      CopyDbfToMySql( "HLCAIXA", .T. )
      fRename( "HLCAIXA.DBF", "HLCAIXA.BAK" )
   ENDIF
   ...


É isso mesmo que parece. Esses DBFs, e outros, vão para o MySQL.
E é isso mesmo que parece também, exatamente a movimentação do caixa, por onde entra e sai dinheiro na empresa, e não pode parar.
Isso mostra minha confiança com ADO + MySQL.
O pessoal vai almoçar usando DBF, e volta usando MySQL - desde que eu chegue lá a tempo de trocar o sistema.

Por enquanto ainda trabalhando nos arquivos aonde só tem inclusão.

Quando só sobrarem os que tem acesso simultâneo pra alteração, aí vou pensar como fazer isso.

De quase 1GB em DBFs iniciais, agora vai reduzir pra quase 20MB.
Tô gostando do negócio.

Nota:
Confiar não significa abrir mão da segurança. Os arquivos serão mantidos como BAK pelo menos até o dia seguinte.
Na próxima rotina de atualização, vai ser só apagar os BAK.

O ADO continua indo

MensagemEnviado: 27 Jun 2016 17:40
por Riggns
Boa tarde, tópico meio antigo já mas estou apanhando do ADO, estou tentando travar um registro para edição e impedir que mais de um usuário acesse um registro ao mesmo tempo, usamos na empresa onde eu trabalho com o DBF, o dbRLock() funciona certinho mas não encontro equivalente para ADODB, é possível fazer isso? futuramente vamos migrar para mysql e a classe que estou fazendo servirá para qualquer tipo de banco de dados.

Desde já obrigado.

O ADO continua indo

MensagemEnviado: 27 Jun 2016 18:14
por JoséQuintas
Ainda não precisei disso.
Como esse cliente é imobiliária, diferente dos demais, é mais tranquilo.

No geral, o último que salvar é o que fica.
A gente é que ficou acostumado a fazer rlock() toda hora, mas isso é desnecessário.

Devo precisar somente no aplicativo de notas fiscais, que TODOS os outros clientes usam.
Inclusive não vou querer deixar opção em DBF, por isso deixando pro final.
Ainda não pesquisei como vou fazer esse bloqueio no tratamento de pedidos.
Vai ser a última parte a migrar.

Em último caso dá pra fazer igual fazia na imobiliária:
Movimentação atual em DBF, e movimentação anterior no MySQL, que não vai sofrer alterações com frequência.
Foi assim que fui transferindo para o MySQL.

O ADO continua indo

MensagemEnviado: 28 Jun 2016 08:11
por Riggns
Entendo JoséQuintas, na verdade é uma mudança de paradigma que isso gera, que na minha opinião é a forma mais correta de se trabalhar, gerar o "ID" somente na gravação, o nosso maior problema seria travar para somente um usuário editar o registro por vez.

Eu vii vários exemplos na internet onde se usa flags para marcar o registro em estado de edição mas nesse caso se o terminal que marcou cair o registro ficaria travado, também não da certo.

Bom, valeu pela ajuda, vou continuar estudando as opções e ver se encontro algo.

Valeu

O ADO continua indo

MensagemEnviado: 28 Jun 2016 11:20
por JoséQuintas
Tem que pensar no seguinte também: o cliente pode até achar ruim o travamento do rlock.
Ele pode considerar que seu aplicativo está com defeito, por não deixar alterar, e outro aplicativo deixar.

Mas cada tipo de atualização pode ser resolvida com tratamento diferente.
Estou esperando chegar lá.

Uma atualização de estoque não é problema.
Ao executar troque conteúdo com conteúdo - 1, o resultado vai estar certo, até melhor que DBF.

Lembre-se do seguinte:

Não é cada estação que vai atualizar o banco de dados.
Os comandos vão para o servidor, e o servidor executa um de cada vez, na ordem em que recebeu.
Nunca vai ter uma gravação do mesmo registro ao mesmo tempo no servidor.
Essa é a principal diferença do DBF, onde obrigatoriamente precisamos bloquear antes de atualizar.

Os tratamentos de bloqueio serão por outros motivos, como isso de dois mexerem no mesmo pedido de uma vez, ou durante a emissão de nota.
Exemplo: durante a emissão da nota, o vendedor cancelar o pedido. Isso sim precisa de algo especial.

O ADO continua indo

MensagemEnviado: 28 Jun 2016 11:31
por JoséQuintas
Só reforçando:

5 terminais atualizam o estoque de uma vez (teoricamente), tirando 1 do estoque.

O servidor vai receber 5 comandos:

atualize estoque = estoque - 1 do produto 10
atualize estoque = estoque - 1 do produto 10
atualize estoque = estoque - 1 do produto 10
atualize estoque = estoque - 1 do produto 10
atualize estoque = estoque - 1 do produto 10


O servidor vai baixar 5 vezes, do produto 10, a quantidade 1.
O resultado vai estar sempre correto.
Isso é diferente do DBF, que grava o número que estiver na memória (cache) - 1
No DBF sim, o resultado é mais imprevisível, e o rlock() dá uma garantia a mais.

O ADO continua indo

MensagemEnviado: 28 Jun 2016 13:55
por Riggns
Boa tarde, entendi a sua explicação, obrigado por responder, o nosso sistema já tem um grande número de clientes e possui 12 anos de mercado, ele trabalha dessa forma travando o registro principalmente nos cadastros, na gravação não temos tanto problema mas sim no momento em que um usuário entra em modo de edição de um cadastro e outro usuários faz a mesma coisa ai temos o problema.

Na forma atual o nosso sistema trava o registro e fica esperando o usuário dar unlock() se outro usuário tentar editar o mesmo registro damos lock no registro e verificamos se tem erro com o neterr() e caso sim travamos a edição para o segundo usuário e avisamos que já está sendo editado.

No ADODB não estou conseguindo travar, estou sem uma solução.

O ADO continua indo

MensagemEnviado: 28 Jun 2016 14:06
por JoséQuintas
Dá uma pesquisada, tem equivalente no MySQL.
Acho até que já foi postado aqui no fórum.