Bug na função dbSelectArea()

[Itamar M. Lins Jr.]

Olá!
Parece que eu ja até entendi o bug
Tem que transformar em CHAR o Numeric... Se colocar "0" vai, assim puro 0 não vai.

[JoséQuintas]

Pois é....
Minhas mensagens só trataram do assunto do post.
Meu post do ppo já mostrou isso que está dizendo agora.

[rochinha]

Amiguinhos,

Chegamos a conclusão que temos uma diferenciação no que se refere a um NUMERAL e que ao usar 0 entre aspas estariámos dizendo a função que "0" é uma palavra assim como "ZERO", "Zero", "NONE", etc.

A função dbSelectArea taca um dane-se se for 0 ou 2874376, não retornando para nós um simples: "idiota, não tá vendo que esta área não existe", porque se é previsto um número máximo de área que podemos abrir deverá ocorrer erro ao ultrapassar o limite ao usar com 0 ou até sem valor.

Tentei examinar os resultados e cheguei a conclusão com base neste teste:

Código: Selecionar todos

#include "fivewin.ch"

function main()

   for nArea = 1 to 10
 
       dbSelectArea( nArea-1 )
       ? "Passo 1", nArea-1, Select()
       // Obtive 0,1 1,1 2,2 3,3 4,4 5,5 6,6 7,7 8,8 9,9

   next

   for nArea = 1 to 10
 
       dbSelectArea( 0 )
       ? "Passo 2", nArea-1, Select()
       // Obtive 0,1 1,1 2,1 3,1 4,1 5,1 6,1 7,1 8,1 9,1

   next

   for nArea = 1 to 10
 
       dbSelectArea( "0" )
       ? "Passo 3", nArea-1, Select()
       // Obtive 0,1 1,1 2,1 3,1 4,1 5,1 6,1 7,1 8,1 9,1

   next

return .t.

Se dbSelectArea( 0 ) ou dbSelectArea( "0" ) criasse uma nova área não haveria tantos 1 repetidos.

Como sempre usei NEW nas aberturas este problema nunca me afetou e creio que a todos nós. Nem sei se poderia ser exposto como bug pois se tentar resolver ou contornar seria como mudar a natureza da chave de fenda só porque um prego não tem rosca.

[JoséQuintas]

No manual cita primeira área livre ou próxima área disponível, dá a entender que não há um número exato.
Seu teste seguiu isso, porque tem horas que retorna o mesmo número, tem horas que retorna o próximo.
Quer dizer, depende do ponto de vista, depende se ele parte da área atual como referência, e isso não seria a primeira de todas, e sim a primeira a partir da atual.

E é considerado bug, porque sempre aceitou número ou letra.
Só deixou de aceitar número na última mexida.

Só deixa confuso mesmo o CH pra SELECT.
Talvez porque o normal é traduzir tudo pra texto, e traduzir 0 pra "0" economiza código extra

[rochinha]

Amiguinhos,

JoseQuintas

Seu teste seguiu isso, porque tem horas que retorna o mesmo número, tem horas que retorna o próximo.

Ele retornou numeros sequencias no Passo 1 apenas, pois numerei as áreas.

No exemplo com 0 ou "0", o fato de não serem criadas novas áreas é porque nos dois casos foi nomeada somente uma área, nunca criando novas mas sim voltando a mesma previamente nomeada.

USE...NEW: Instead of using SELECT 0 and USE <xcDatabase> to
open a database file in a new work area, the preferred method is to
USE <xcDatabase> NEW.

Encontrei isto em https://www.itlnet.net onde fala de SELECT 0 que no nos .CHs é traduzido por dbSelectArea( <(area)> ) sendo assim, existe o bug.

Usei a seguinte versão para testes:

c:\temp>harbour
Harbour Compiler Alpha build 45.0 (Flex)
Copyright 1999-2005, http://www.harbour-project.org/

[JoséQuintas]

No meu caso, eu uso pra algo mais

Código: Selecionar todos

FUNCTION AbreArquivo( cFile )
   SELECT ( Select( cFile ) )
   USE
   USE ( cFile )
   RETURN .T.

Se o arquivo já estiver aberto, vai retornar a área aonde ele está aberto, nesse caso já fecha e reabre.
Se não estiver aberto, retorna zero, então abre em uma área nova.
Isso garante que vai abrir exatamente arquivo e índices do jeito que precisa, independente de como foi aberto antes.
E vai usar mesma área, ou área nova.
Não precisa nem teste adicional.
Esse uso é diferente de apenas selecionar área nova
E precisaria mais fonte, se fosse diferente.

o USE é pra fechar.
Numa época dava erro o USE de arquivo já aberto, mesmo sendo na mesma área.
Sabemos que vai fechar o anterior primeiro, mas isso não era levado em conta.
Pode ser que isso mudou, pode ser que não.
Não lembro se o problema foi com Clipper, Harbour, flagship, ou outro.