Quando utilizamos uma tabela ou arquivo local, através da RDD c-tree, independente de usarmos c-tree Local ou c-tree Server, o path completo de acesso ao arquivo é guardado no header (cabeçalho interno) deste arquivo. Caso um arquivo seja criado em um determinado path e o arquivo ou o path seja renomeado, ou seja copiado para outro path e aberto pelo sistema, o servidor de aplicação identifica que o Path de acesso atual do arquivo não corresponde ao path de criação do arquivo e, automaticamente, atualiza o path do header do arquivo com o path e nome do acesso atual, e faz automaticamente o rebuild dos índices permanentes deste arquivo.
Existe uma ocorrência de falha no rebuild, que pode ser reproduzida mediante o uso de uma configuração de ambiente inadequada, onde mais de um serviço do servidor de aplicação fazem acesso ao mesmo ROOTPATH de ambiente (por exemplo, um ambiente de balanceamento de carga), onde o ROOTPATH dos ambientes foi configurado de forma diferente nos servidores de aplicação: Por exemplo, na máquina onde está fisicamente a pasta correspondente ao ROOTPATH do ambiente, a configuração de ROOTPATH , no arquivo de configuração, foi especificada usando a unidade de disco local (exemplo: C:\Protheus10\Ap_test\advpltests_top_ctree), e em um serviço slave do ERP, que acessa este mesmo ambiente, o ROOTPATH foi especificado utilizando um endereço de rede (\\172.16.84.110\p10$\ap_test\advpltests_top_ctree).
Num cenário como este, supondo que a primeira aplicação AdvPL que seja executada e abra os dicionários seja iniciada no serviço do servidor de aplicação configurado com path local. No momento da abertura, caso o path de acesso seja o mesmo do registrado no header do arquivo, o arquivo é aberto sem a necessidade de rebuild. Este usuário entrou no sistema e mantém o remote aberto com o sigamat.emp e dicionários abertos.
Enquanto isso, o mesmo usuário ou outro usuário tenta acessar o sistema a partir do serviço do servidor de aplicação configurado para acesso ao mesmo ambiente, porém o ROOTPATH está configurado para acessar as tabelas através do caminho de rede (\\172.16.84.110\p10$). Neste caso, quando a aplicação abrir uma tabela usando o c-tree (no caso do ERP, será a tabela de Empresas (sigamat.emp)), o driver não consegue abrir a tabela, pois o path de acesso registrado no header (c:\protheus10\... ) não é o mesmo que está sendo usado agora (\\172....). Então, automaticamente, o servidor de aplicação inicia um rebuild da tabela e dos índices para atualizar o path de acesso. Porém, a tabela está aberta e em uso por outro processo o que impede que o rebuild dos índices seja realizado. Neste caso, será registrado no log de console do servidor de aplicação a seguinte mensagem:
************************ (TEC-AUTOQUAD,juliow) ************************Ctree Error: Could not Update internal index name - 12 - Could not open file: not found or locked - File: \\172.16.84.110\p10$\ap_test\advpltests_top_ctree\system\sigamat E, imediatamente após esta mensagem, a aplicação Advpl será finalizada com a ocorrência de erro abaixo :/*-------------------------------------------------------ERRO THREAD ([1484], juliow, TEC-AUTOQUAD) 19/02/2010 13:55:22 Stack :\\172.16.84.110\p10$\ap_test\advpltests_top_ctree\system\sigamat.emp: Ctree Error - Open - Internal index name could not be updated on MSOPENDBF(APLIB070.PRW) 08/02/2010 line : 56[build:7.00.090818P][environment: advpltests_top_mssql2][thread 1484][remark: Emp :/xx Logged : SIGAFIN Obj :Main Window]Called from OPENSM0(APLIB100.PRW) 30/01/2010 line : 1332Called from NEWEMPR(APLIB090.PRW) 30/01/2010 line : 626Called from VALSENHA(APLIB090.PRW) 30/01/2010 line : 2719Called from {|| (CURSORWAIT(),OPSW:OGET:ASSIGN(),OPSW:OGET:UPDATEBUFFER(),LSENHA:=VALSENHA(CPSW,@AUSUARIO,@OPSW,@AEMPRX,@OCBX,@CEMPRFIL,CNOME,ACONFIG,@NERROS,@ONOME,@AAMB,AAMBAUX,@OCBXAMB,CAMB,, .T. ,__LLOGOFF),MSSAUDACAO(LSENHA),CEMPRESA:=CNUMEMP,CURSORARROW(),IF(LSENHA,EMPROK(CEMPRESA),),LSENHA)}(APLIB090.PRW) line : 263Called from ::MSDIALOG:ACTIVATE line : 0Called from GETSENHA(APLIB090.PRW) 30/01/2010 line : 467Called from ABERTURA(APLIB090.PRW) 30/01/2010 line : 65Called from {|| BUILDMSGITEM(OMAINWND),APPINIT(),ABERTURA(OMAINWND),IF(SELF:BAPPINIT <> NIL,EVAL(SELF:BAPPINIT),)}(APLIB000.PRW) line : 862Called from ::TWINDOW:ACTIVATE line : 0Called from MSAPP:RUNAPP(APLIB000.PRW) 06/02/2010 line : 876Called from SIGAFIN(APLIB000.PRW) 06/02/2010 line : 2585-------------------------------------------------------*/
Outros cenários inválidos
Esta ocorrência pode também ser reproduzida quando utilizamos um c-tree Server com balanceamento de carga ou mais de um serviço acessando os SXs do msmo ambiente, onde obrigatoriamente deve-se especificar o ROOTPATH dos ambientes com um caminho de rede e obrigatoriamente devemos especificar a configuração da chave CtreeRootPath em todos os ambientes. Porém, ao configurar um dos servidores, não foi colocada a chave CtreeRootPath.
Procedimento recomendado
Neste caso, uma vez que um ambiente e seu ROOTPATH com dicionários e afins seja compartilhado para mais de um serviço, do servidor de aplicação, para ser acessado por serviços que executam em outras máquina da rede (como no balanceamento de carga, por exemplo), inicialmente deve-se utilizar um driver de controle de dicionários com arquitetura Client-Server (como o ADS Server e/ou c-tree Server) e, em TODOS os serviço do servidor de aplicação que acessem este determinado ambiente, o ROOTPATH deste ambiente, em todos os serviços, inclusive os serviços da própria máquina onde está a unidade de disco e path físico onde estão estes arquivos, deve ser configurado o ROOTPATH para acessar os arquivos pelo compartilhamento de rede, para os ROOTPATH ficarem iguais. Adicionalmente, com o uso do c-tree Server, deve-se colocar a chave CTreeRootPath em todos os ambientes, onde será especificado o caminho físico dos arquivos na máquina onde os arquivos estão e, consequentemente, está instalado o c-tree Server que fará acesso a estes arquivos.