Meu modo de trabalho

[JoséQuintas]

E não é que me vejo à tarde mexendo com DBFs !!!!

Estou alterando minha imitação de dbase pra aceitar campos incrementais.

E vou usar campos incrementais pra facilitar a migração pra MySQL.

Pois é... coisas da vida... melhorando DBF pra usar MySQL kkkkk

E usar um recurso que nunca usei do DBF, que é o campo incremental.

[JoséQuintas]

E uma rotina um pouco fora do normal:

Código: Selecionar todos

   CASE cEncode == "mixbase64"
      IF Empty( xValue )
         xValue := Nil
      ELSE
         xValue := MixValue( hb_base64Decode( xValue ) )
      ENDIF
   ENDCASE
   IF xValue == Nil .OR. Empty( xValue )
      cName := Lower( cName )
      DO CASE
      OTHERWISE
         lWriteError := .T.
         FOR nCont = 1 TO 15
            IF ! Empty( ProcName( nCont ) ) .AND. hb_ASCan( { "SENDMAIL" }, { | e | e $ Upper( ProcName( nCont ) ) } ) != 0
               lWriteError := .F.
               EXIT
            ENDIF
         NEXT
         IF lWriteError
            Errorsys_WriteErrorLog( "Faltou o binario " + cName, 2 )
         ENDIF
      ENDCASE
   ENDIF

Coloquei pra avisar quando falta resource no MySQL, mas tá vindo aviso demais, então vou começar a filtrar o tipo de erro.
É que nem todos usam logotipo, por exemplo.
Além disso, faltava a indicação de que parte do programa está reclamando do resource.

Código: Selecionar todos

Faltou o binario gargantua.jpg  
Called from ZE_BINARYFROMSQL(210)
Called from SENDMAIL:SETDEFAULT(80)
Called from SENDMAIL:SEND(152)
Called from JPALOGERRO(62)
Called from SISTEMA(33)
Called from (b)MAIN(77)

Imagem pra email.... não é obrigatório existir...

[JoséQuintas]

Atualizei minha imitação de dbase pra aceitar campo incremental.
É a primeira vez que estou usando o campo incremental, e ele não estava preparado pra isso.

[Itamar M. Lins Jr.]

Olá!
Já usei esse e outro que coloca a data sozinho e mais o DATE TIME, 3 tipos novos, e tem mais outros como tamanho variado, BLOB...

Saudações,
Itamar M. Lins Jr.

[Poka]

Boa tarde,

Quintas, não sei como os outros fazem, mas se eu fizer do seu jeito não ia conseguir nunca.
Ás vezes que mudei de versões faço assim:

Faço o sistema novo, faço as rotinas para passar todas as tabelas do antigo para o novo. e vou testando, depois de tuuuudo pronto, atualizo a base de dados do antigo do cliente, confiro os relatorios, ct receber, pagar, tudo. se tudo ok, vou no cliente atualizo a base atual do antigo para o novo.

Então fica assim, o cliente termina hoje com o sistema antigo e amanha começa no novo. Deixo em um cliente só, se der erro vou acertando. depois atualizo os outros.

Gostaria até da opinião dos colegas como fazem, porque realmente é complicado.

Poka

[Itamar M. Lins Jr.]

Olá!

faço as rotinas para passar todas as tabelas do antigo para o novo.

Faço isso, sem problema até hoje, pois sou eu que faço a atualização ou modificação das estruturas do DBF.
Uso uma função para isso.
É simples.
a) comparar as estruturas do DBF.
b) se achar diferençar, pegar a NOVA estrutura e criar um arquivo temporário.
c) importar do velho para o novo DBF os dados das estrutura que já existem.
d) RENOMEAR

Apagar só depois e se desejar. Não tem DELETE durante o processo.

Esse processo falha se por exemplo mudar campo numeric para character e deixar o mesmo nome no FIELD. Mas pode ser resolvido com função se for o caso.

Saudações,
Itamar M. Lins Jr.

[alxsts]

Ol[a!

Há algum tempo testei esta funcionalidade e esta ok. Mas a forma como defini a coluna usa o sinal de + para definir o tipo de dados:

Código: Selecionar todos

  AAdd( aArray, { "idUF",      "+",  4, 0 } )

Estou vendo no post acima I:+ definir o tipo de dados. De onde veio isto? Está documentado? Qual é a diferença?

[Itamar M. Lins Jr.]

Olá!

Estou vendo no post acima I:+ definir o tipo de dados. De onde veio isto? Está documentado? Qual é a diferença?

É a mesmo coisa.
Ou sinal ou LETRA + SINAL.

Também uso só "+" ou "@" ou "T"

Saudações,
Itamar M. Lins Jr.

[alxsts]

Olá!

Ok, obrigado. Pensei que tinha algo a ver com "Integer", qu também é aceito no Harbour.

[Itamar M. Lins Jr.]

Olá!
É isso mesmo, pois o + é para dizer que auto incremento.

Detalhe que se for usar o DBF em 32Bit é 4 e 64Bit é 8 no campo numéric. (pelo que andei lendo)

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
Aqui um exemplo, que fiz no Linux, tudo WEB via CGI.

Código: Selecionar todos

*****************************
Function CriaStruCentroCustos
*****************************
*
*
LOCAL lShared := .F.
LOCAL aStru := {{"idcc"      ,"+",04,0},;
                {"centrocust","c",30,0},;
                {"descricao" ,"c",50,0},;
                {"diainclu"  ,"@",08,0},;
                {"diamodif"  ,"=",08,0},;
                {"incluido"  ,"c",20,0},;
                {"alterado"  ,"c",20,0}}
                
IF !hb_FileExists("../dados/centrocustos.dbf")                
   If !dbcreate("../dados/centrocustos.dbf",aStru,"DBFCDX")
      Return ErrorHTML( "Erro criando arquivo: centrocustos.dbf" )
   EndIf
ELSE
   ChkEstrDBF("../dados/centrocustos.dbf",aStru)
ENDIF

Return ""

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Teve uma época que o incremental não podia ser editado.
Não sei se tem a ver.
E apesar de indicar que pode ser qualquer tipo de numérico, só deu certo com o I:+
É tipo integer mesmo, porque o tamanho é de 4 bytes e no changelog menciona 8 bytes pra 64 bits.

[JoséQuintas]

Quintas, não sei como os outros fazem, mas se eu fizer do seu jeito não ia conseguir nunca.
Ás vezes que mudei de versões faço assim:
Faço o sistema novo, faço as rotinas para passar todas as tabelas do antigo para o novo. e vou testando, depois de tuuuudo pronto, atualizo a base de dados do antigo do cliente, confiro os relatorios, ct receber, pagar, tudo. se tudo ok, vou no cliente atualizo a base atual do antigo para o novo.
Então fica assim, o cliente termina hoje com o sistema antigo e amanha começa no novo. Deixo em um cliente só, se der erro vou acertando. depois atualizo os outros.
Gostaria até da opinião dos colegas como fazem, porque realmente é complicado.

O lado ruim é não poder tirar proveito enquanto não estiver tudo em SQL.
Tem muita tabela que dá pra transferir instantâneo, de pouco uso, ou só pra validação, então essas dá pra transferir de imediato.
Tem tabela aonde dá pra alterar a gravação, pra salvar nos dois, então é primeiro alterar com o DBF como principal, e depois com o SQL como principal.
Feito isso com as gravações, dá pra alterar os relatórios e consultas pra usar SQL em plena carga, um de cada vez.

Fica sempre em uso, sempre em teste, melhor do que trocar de uma vez e ter muitas surpresas.
É continua recebendo atualizações, o que não é possível se tiver fontes diferentes.

É que ninguém pediu, ninguém está precisando, ninguém está pagando por isso, e o melhor: ninguém está pressionando.
Então é ir fazendo conforme facilitar mais.
Dá tempo de voltar atrás, eu encontrar uma solução melhor.

E tá tudo sempre atualizado.
Considero sempre que o fonte que estou mexendo pode entrar em uso nos próximos minutos.
Melhor do que ficar mexendo em fontes diferentes pra cada situação, o que só aumentaria o trabalho e estaria sujeito a erros e complicações.

É instalar versão nova pra resolver um pipino que pode ter acontecido, e já instalar recursos novos.

[JoséQuintas]

Esqueci de dizer, e também esqueci disto:

ACABOU meu uso de HBNETIO.
Vou apagar as poucas linhas que existiam nos fontes pra isso.

Vou apagar, por exemplo, isto:

Código: Selecionar todos

FUNCTION PathAndFile( cFileName )

   IF AppDatabase() == DATABASE_HBNETIO
      cFileName := "net:" + AppEmpresaApelido() + "/" + cFileName
   ENDIF
   cFileName := Lower( cFileName )

   RETURN cFileName

[JoséQuintas]

Não que faça diferença mas..... encolheu um pouquinho.

Menu aplicativo tem até....

Código: Selecionar todos

            MenuOption( "Remoto Sony",               "PTESREMSONY" )

Isso é pra pesquisar os códigos de configuração do meu controle remoto kkkk