Infra

Thiago C.

Resetar senha do Administrador do Protheus

Dica de ouro para quando esquecemos a senha de admin do Protheus, mas não podemos nos dar ao luxo de descartar todo o arquivo de senhas e, consequentemente, os perfis de usuários.

Siga os passos abaixo à risca:

1) Renomeie o arquivo sigapss.spf na pasta system e guarde-o.

2) Abra o configurador para que o sistema recrie o arquivo permitindo a entrada com usuário admin e senha em branco.

3) Saia do sistema.

4) Crie e compile o fonte:

#INCLUDE "TOTVS.CH"

User Function SPFCLOSE()

    SPF_CLOSE("SIGAPSS.SPF")

Return( Nil )

5) Entre novamente no SIGACFG e acesse a o cadastro de Fórmulas.

6) Inclua uma fórmula, digite na função U_SPFCLOSE() e pressione ENTER.

7) Ainda com o Cadastro de Fórmulas aberto, vá até a system para excluir o arquivo recém criado sigapss.spf e renomeie novamente o arquivo original.

8) Ainda no SIGACFG, cancele o cadastro e saia da rotina de Fórmulas. Acesse o cadastro de usuários, altere o Administrador e defina a senha livremente.

Anúncios
Thiago C.

Atualizações Protheus 12

Fala pessoal. Eu estava enfrentando muitos problemas com a quantidade gigantesca de patches disponíveis desde o último RPO do P12, seja 12.1.7 ou 12.1.14. Para aplicar é impraticável, na 12.1.7 são mais de 2000 patchs desde 01/08/2016 (último RPO disponível).

Outro problema sério que ocorre é que quando filtramos os patchs de programa por banco de dados/idioma (ex. Top Connect Português), vêm um número muito pequeno de patchs. E quando filtramos apenas o release sem distinção de banco de dados e idioma aparecem milhares. Dentro delas, após descompactar, verificamos que todas as variações de PTM estão lá dentro (TTTP, TTTS, TTTE, TTDP, TTDS, etc. etc.).

Então o filtro está “escondendo” muita coisa. Por isso já faz um bom tempo que recomendo não filtrar por banco dados e idioma. Isso realmente está um pouco confuso. Acho que o portal pode estar sofrendo uma manutenção grande nos últimos meses.

Mas tenho uma boa notícia. Agora a TOTVS criou uma nova categoria chamada “Patches Acumulados” que salvou a pátria! Esses acumulados já existiam, mas se perdiam entre tantos patches na lista.

Cursor_e_TOTVS_S_A_-_Downloads_e_Atualizações

 

Enfim, agora não precisamos aplicar os inúmeros patches. Essa categoria nova praticamente substitui a “Patch de Programa”. Mas não totalmente, porque a categoria “Patch de Programa” ainda continuará servindo para baixarmos patches recentes que ainda não saíram em um acumulado ou então alguma bem específica pra atender a uma demanda num ambiente que ainda não está pronto pra ser totalmente atualizado.

Bom, essa informação não é oficial. Estou compartilhando com vocês a minha experiência nos últimos meses, e essa novidade que surgiu semana passada que vai ajudar bastante nas atualizações e migrações.

Forte abraço e até a próxima dica 😉

Thiago C.

Dividir licenças entre DBAccess

O ambiente ideal para testes na empresa deve ser totalmente apartado, inclusive com DBAccess próprio. Para apontar dois DBAccess para um mesmo License Server é preciso definir quantas licenças cada um irá consumir pois, senão, o primeiro que se conectar ganha todas e o outro fica apenas com as 2 de demonstração. Isso é bem ruim quando o primeiro a se conectar é o de testes, ficamos sem licenças suficientes para a produção.

A solução é bem simples. Após instalar e configurar os dois DBAccess, faça a divisão através da cláusula LicenseLimit no DBAccess.ini. Os dois DBAccess devem ter essa configuração, senão não adianta.

Digamos que você tenha 50 licenças Top Connect, veja o exemplo de configuração abaixo para que reservemos 15 licenças para teste e o restante (35 licenças) para a produção.

DBAccess de Produção:

[General]
LicenseServer=10.20.20.28
LicensePort=5555
ByYouProc=0
...
LicenseLimit=35 <-- Olha ela aqui

DBAccess de Teste:

[General]
LicenseServer=10.20.20.28
LicensePort=5555
ByYouProc=0
...
LicenseLimit=15 <-- Olha ela aqui

IMPORTANTE: após configurar, desligue os dois DBAccess e inicie-os novamente.

Thiago C.

Semáforo no License Server

p_semaforo-repetidor-14Rotinas que utilizam semáforo, como por exemplo, as da contabilidade. Internamente fazem uso das funções LockByName e UnlockByName já explicadas aqui neste blog.

De um tempo pra cá, essas funções, por padrão, passaram a controlar o semáforo através do License Server.

Mas quando sua base de testes e sua base de produção utilizam o mesmo License Server (o que acontece em quase todo lugar), um processamento num ambiente acaba travando o outro ambiente via semáforo.

Para solucionar esse problema inclua a cláusula SpecialKey no ambiente do AppServer.ini do Protheus de testes. Segue um exemplo:

[TESTE]
SourcePath=D:\TOTVS12Teste\Protheus\apo
RootPath=D:\TOTVS12Teste\Protheus_Data
StartPath=\system\
x2_path=
RpoDb=Top
RpoLanguage=portuguese
RpoVersion=120
LocalFiles=CTREE
Trace=0
localdbextension=.dtc
PictFormat=DEFAULT
DateFormat=DEFAULT
RegionalLanguage=BRA
TopMemoMega=1
HelpServer=192.168.10.247:8079
SpecialKey=BaseDeTestes <--- Olha ela aí
Thiago C.

Permissões para TDS aplicar patchs e editar appserver.ini

Adicione as cláusulas abaixo no AppServer.ini do serviço Protheus para que seja possível aplicar patchs e editar o INI do server diretamente pelo Totvs Developer Studio.

[TDS]
AllowApplyPatch=*
AllowEdit=*

Esse asterisco indica que qualquer TDS em qualquer máquina, que tenha feito conexão com  o servidor, poderá aplicar patchs ou editar o INI. Mas é possível inserir apenas os IPs que você desejar permitir, separados por vírgula.

Veja a documentação completa sobre cada uma dessas cláusulas no TDN:

AllowApplyPatch: https://goo.gl/JuaKBh
AllowEdit: https://goo.gl/RIaI7A

Thiago C.

Usando TCLink para conectar a outra base de dados

php-db-connection

Olá meus amigos! Andei um pouco sumido, mas vou me esforçar em continuar postando conteúdo por aqui. Vamos falar de conexão com outros bancos de dados de dentro do Protheus.

Com as funções AdvConnection(), TCLink() e TcSetConn() podemos nos conectar a outras bases de dados através do DBAccess (TopConnect). Lembrando que primeiramente temos que seguir a configuração padrão que é criar a conexão ODBC no servidor onde está instalado o DBAccess e depois configurar no próprio DBMonitor como já fazemos com a base Protheus.

No nosso fonte, bastará alternar entre os bancos de dados para realizar consultas e comandos SQLs. Veja abaixo um exemplo simples para se conectar a um banco que chamamos de GRUPOBI onde o DBAccess se encontra no mesmo servidor da aplicação escutando na porta 7890.

Local cConexao    := SuperGetMV("MV_XXCON01", .F., "MSSQL/GRUPOBI")
Local cServerAddr := SuperGetMV("MV_XXCON02", .F., "localhost")
Local nPort       := Val(SuperGetMV("MV_XXCON03", .F., "7890"))

If Type("_nTopProtheus") == "U"

    Public _nTopProtheus

    _nTopProtheus := AdvConnection() // obtém o ID da conexão atual

EndIf

If Type("_nTopGrupoBI") == "U"

    Public _nTopGrupoBI

    MsgRun("Conectando a Grupo BI...","Conexão",;
        {|| _nTopGrupoBI := TcLink(cConexao,cServerAddr,nPort) })

    If _nTopGrupoBI < 0

        MsgAlert("Não foi possível se conectar com Grupo BI. "+;
                 "Essa falha pode ocorrer devido ao número de licenças excedidas. "+;
                 "Tente mais tarde ou contate o administrador do sistema.")

        Return .F.

    EndIf

EndIf

TcSetConn(_nTopGrupoBI) // Utilize essa função para alternar entre as conexões

Você precisará de permissão para criação de tabelas no banco, pois o Protheus criará automaticamente nesta base as seguintes tabelas de controle do DBAccess: TOP_PARAM, TOP_SP, TOP_VIRTUALIDX, TOP_FIELD e TOP_IDXSTATS.

Vejam mais informações no TDN: http://tdn.totvs.com/display/tec/TCSetConn

Thiago C.

Protheus 11.8 DEMO atualizado em 26/08/2015

Estou disponibilizando dois downloads do Protheus 11.8 atualizado até 26/08/2015 para simulação, desenvolvimento e estudo, conforme a Totvs permite, operando na empresa 99-Teste com 2 acessos no DBAccess (Top Connect). Os arquivos estão compactados em RAR5, por isso você precisa ter uma versão atualizada do seu descompactador.

–

Pastas Protheus e Protheus_Data

Podem ser utilizadas para uma nova instalação do Protheus.

Link para download: https://goo.gl/x0aC6U (722 MB)

–

Máquina Virtual

Máquina virtual com Windows XP SP2 + SQL Server + Protheus funcionando como serviço. É uma máquina virtual para o Oracle VirtualBox.

Atualização do post em 28/03/2017: pessoal, percebi que realmente fazer o download no Mega está complicado. Então segue aqui o link de download da máquina virtual pelo Google Drive, o arquivo está dividido em partes de 1 GB. Tive vários problemas pra conseguir isso mas funcionou, porém ficou maior a maquina virtual. Mas enfim, funciona.

Link para download no Google Drive: https://goo.gl/XM6Vh9 (10 arquivos RAR em partes totalizando 10 GB)

Link para download no Mega: https://goo.gl/hLf0H1 (5,06 GB)

Baixe o Oracle VirtualBox nesse link: https://www.virtualbox.org/wiki/Downloads

–

Screenshots da máquina virtual

vm_tela1

vm_tela2

vm_tela3

vm_tela4

vm_tela5

Imagem Thiago C.

Problema ao restaurar backup no SQL Server

Algumas vezes pode ocorrer um problema muito chato ao restaurar um backup no SQL Server. É quando, após a restauração, o status do banco de dados permanece (restaurando) ou (restoring) e o SQL Server não permite nenhuma operação nessa base. Pesquisei na internet e descobri que o problema pode ocorrer no término da criação do arquivo de log. É um bug, mas a restauração foi bem sucedida. Encontrei uma solução extremamente simples para desbloquear o banco de dados. Acesse o Management Studio, conecte ao SQL Server, e execute o seguinte comando SQL:

RESTORE DATABASE NOME_DO_BANCO WITH RECOVERY

Pronto. Problema solucionado.

Thiago C.

Limite de Memória no SQL Server

Adicionalmente ao post que eu fiz sobre Configuração de Balance no Protheus gostaria também de compartilhar uma configuração muito simples e que pode salvar servidores que estão à beira de um colapso, especialmente quando as aplicações do Protheus e o SQL Server rodam na mesma máquina. Essa situação (aplicações e banco no mesmo servidor) não é muito recomendada quando a empresa começa a exigir mais do sistema (a partir de 30 usuários simultâneos; ou quando se utiliza rotinas de processamento com certa frequência). Mas sabemos que nem todos possuem estrutura ($$$) suficiente para um dimensionamento ideal. Dessa forma, travamentos no sistema podem ser resolvidos com o Balance que expliquei anteriormente. Mas a lentidão ainda existirá. Resolvê-la completamente é outra história. Exige realmente um correto dimensionamento dos servidores, de preferência feito por um Analista de Infra e um bom DBA (eu não sou nem um nem outro!).

No entanto, podemos reduzir bastante a lentidão e praticamente nos livrar de travamentos no servidor por estouro de memória. Sabemos que o Windows Server não faz um gerenciamento de memória perfeito, portanto quando falei sobre o Balance expliquei que o ideal é que os appservers do Protheus não trabalhem com mais de 1 GB de memória cada. Acompanhando esse raciocínio, devemos então entender que o servidor precisa ter disponível esse 1 GB de memória RAM para cada appserver que configuramos. Quando temos uma demanda de 20 a 40 usuários, o SQL Server roda muito bem com 2 GB de RAM dedicados. Mas no padrão, o SQL Server utiliza TODA a memória disponível do sistema, e isso não é nada bom, pois o Windows Server frequentemente se enrola. Precisamos resolver isso! Então devemos definir no SQL Server um limite máximo de uso de memória.

(1) No Management Studio, clique com o botão direito no servidor conectado.

(2) Em seguida, clique em Propriedades ou Properties.

memsql_1

 

(3) Acesse a página Memória ou Memory.

(4) Edite o campo Maximum server memory ou Memória máxima do servidor.

memsql_2

Pronto. Ao confirmar essa tela, imediatamente você poderá ver no monitor de recursos ou gerenciador de tarefas, que o SQL Server agora ocupará no máximo o número que você determinou. Lembrando que você somente conseguirá editar essa configuração se for o administrador do SQL Server.

Assim, se configuramos um balance com 1 master e 3 slaves, por exemplo, ter um servidor com 8 GB de memória RAM é suficiente, pois deixamos 2 GB para o próprio Windows Server que trabalhará com uma folga + 4 GB para os appservers + 2 GB para o SQL Server.

Mais uma vez quero deixar claro de que não sou um expert em Infra tão menos um DBA. Minhas dicas são com base na minha experiência no mercado atendendo empresas de médio e grande porte como consultor de negócios, analista e programador, onde eventualmente me deparo com problemas no servidor e preciso dar solução imediata. Então, por favor, não considerem as minhas dicas como a última verdade!

Mas elas funcionam 😉