Para os que dormem sobre um get/read aberto
Enviado: 16 Jun 2008 20:29
Pessoal
Procurei em todo o forum solução para um problema que eu tinha e que também outros tem ou já tiveram: Como tratar de dar um "chega pra lá" naqueles amáveis usuários que "dormem" sobre um registro bloqueado e não saem nunca do modo de edição.
A solução mais prática que vi foi o uso da função KeySec().
Mas bolei uma solução tupiniquim, que resolveu bem o meu problema, embora seja aplicável apenas aos casos get/read. Acho que com um TBrowse já não dá pra usar. Mas vamos lá:
O macete é não bloquear o registro para edição. Apenas permita que o gajo leia o registro em questão e atribua a variáveis os valores dos diferentes campos.
O registro só é bloqueado no instante que o cara cair fora do read.
Tipo assim:
1) Atribua a variáveis os valores dos campos:
global xCampo[fcount()]
for i = 1 to fcount()
xCampo := fieldget(i)
next
2) Depois crie o conjunto get/read:
@ 2, 4 SAY Fieldname(1) color cColor1 GET xCampo[1] color cColor2 //ANOMES
@ 2, 24 SAY Fieldname(2) color cColor1 GET xCampo[2] color cColor2 //LOTE
@ 2, 34 SAY Fieldname(3) color cColor1 GET xCampo[3] color cColor2 //DIG
@ 2, 44 SAY Fieldname(4) color cColor1 GET xCampo[4] color cColor2 //DOM
@ 2, 54 SAY Fieldname(5) color cColor1 GET xCampo[5] color cColor2 //FAM
@ 2, 64 SAY Fieldname(6) color cColor1 GET xCampo[6] color cColor2
.
.
.
read
3) Quando o read for liberado, grave
if updated()
try
rlock()
for i = 1 to fcount()
fieldput(i, xCampo)
next
dbcommit()
dbunlock()
catch
//Aqui eu coloquei uma rotina para gravar em outro banco de dados os casos em que //deu rolo. Até este momento não houve nenhum registro de ocorrencia de problemas.
end
endif
Pode ser que já tenha sido postado sobre isto, mas achei que valia a pena registrar.
Até
Procurei em todo o forum solução para um problema que eu tinha e que também outros tem ou já tiveram: Como tratar de dar um "chega pra lá" naqueles amáveis usuários que "dormem" sobre um registro bloqueado e não saem nunca do modo de edição.
A solução mais prática que vi foi o uso da função KeySec().
Mas bolei uma solução tupiniquim, que resolveu bem o meu problema, embora seja aplicável apenas aos casos get/read. Acho que com um TBrowse já não dá pra usar. Mas vamos lá:
O macete é não bloquear o registro para edição. Apenas permita que o gajo leia o registro em questão e atribua a variáveis os valores dos diferentes campos.
O registro só é bloqueado no instante que o cara cair fora do read.
Tipo assim:
1) Atribua a variáveis os valores dos campos:
global xCampo[fcount()]
for i = 1 to fcount()
xCampo := fieldget(i)
next
2) Depois crie o conjunto get/read:
@ 2, 4 SAY Fieldname(1) color cColor1 GET xCampo[1] color cColor2 //ANOMES
@ 2, 24 SAY Fieldname(2) color cColor1 GET xCampo[2] color cColor2 //LOTE
@ 2, 34 SAY Fieldname(3) color cColor1 GET xCampo[3] color cColor2 //DIG
@ 2, 44 SAY Fieldname(4) color cColor1 GET xCampo[4] color cColor2 //DOM
@ 2, 54 SAY Fieldname(5) color cColor1 GET xCampo[5] color cColor2 //FAM
@ 2, 64 SAY Fieldname(6) color cColor1 GET xCampo[6] color cColor2
.
.
.
read
3) Quando o read for liberado, grave
if updated()
try
rlock()
for i = 1 to fcount()
fieldput(i, xCampo)
next
dbcommit()
dbunlock()
catch
//Aqui eu coloquei uma rotina para gravar em outro banco de dados os casos em que //deu rolo. Até este momento não houve nenhum registro de ocorrencia de problemas.
end
endif
Pode ser que já tenha sido postado sobre isto, mas achei que valia a pena registrar.
Até