Tabela temporária em memória

[rmlazzari]

Ops! Desculpe, não tinha visto:

Desculpem por tanto post, mas é algo muito interessante, e pelo jeito causa algum bug no recurso do Harbour.
Se no seu Windows acontece isso, não é arquivo em memória, e precisaria relatar o bug.

No meu caso, o .dbf está funcionando direitinho. Chama-se "rollback.dbf" e serve para ir voltando os "palpites" no Sudoku, o conhecido Ctrl-Z, um a um. Eu não indexei porque, se "locate for" no HD é lerdo, na RAM, é instantâneo. E na verdade nem comando de busca eu dou, quando quero voltar uma jogada, vou ao bottom do rollback.dbf, pego o último, transfiro para variáveis, "DELETE/PACK" e um abraço. É instantâneo mesmo.

Agora, que o pessoal do Harbour, vocês ponham atenção nisso... é por isso que a turma confia no Harbour, né? )

[rmlazzari]

Sim, verdade: se é mentira que o arquivo está sendo criado na RAM, isso é um perigo!

Dá uma olhadinha nesse programa que falei, da NirSoft. Ele enxerga os "streams" direitinho, e permite deletar. Que deletou dá prá saber facil: depois daquela deleção que fiz, o desfragmentador acusou milhares de clusters vazios, salpicados no HD... E no segundo post desse tópico, escrito pelo colega Daniel, dá a entender que pelo menos o ponteiro desse stream está no HD.

http://www.nirsoft.net/utils/alternate_ ... reams.html

[JoséQuintas]

Eu fui pelo lado prático: na época alterei o aplicativo inteiro pra usar isso, só por curiosidade.
O aplicativo funcionou normalmente, como se fosse um diretório, tudo salvo lá dentro.
E tanto faz reiniciar a máquina, continua tudo lá.

E sempre mostrando como tamanho ZERO.

Seja qual for a explicação técnica, na prática funciona como um diretório oculto.

Rodei esse utilitário aqui por curiosidade.
Ele acabou indicando stream em arquivos normais, arquivo ZIP de backup, por exemplo.
Curioso é que só alguns ZIPs apareceram na lista.

[rmlazzari]

Fiz um teste aqui, caro Quintas, e...

Mandei o "AlternateStreamView" vasculhar meu HD. Encontrei um monte de "streams", quase todos eles dos filmes que falei. Pedi para deletar todos mas o programa não conseguiu deletar dois.

Aí entrei no Sudoku.exe, mandei vasculhar de novo e... não é que o arquivo estava lá, no HD mesmo?
Com o nome de ":rollback.dbf:$DATA", tinha 195 bytes e ocupava 200 bytes em disco.

Aí enchi o tabuleiro de jogadas (e para cada jogada, o sistema aumenta um registro no rollback.dbf) e mandei vasculhar de novo. Agora o ":rollback.dbf:$DATA" tinha 1.048.576 bytes e alocava o mesmo tanto (1MB).

Saí do sudoku.exe (e na saída deleto o "mem", que nos é visível), vasculhei de novo e o tal de ":rollback.dbf:$DATA" tinha sumido.

Acho que o NTFS tá fazendo a gente de bobo... Bem, esmola demais, cego desconfia. "Tabela na RAM", bah! Já pensou a velocidade, se fosse verdade e fosse com um um tabelão? HD solid state "de grátis", rs...

[JoséQuintas]

Rodei aqui de curiosidade.
Na lista acima, o favorito do meu site, mostrando o ícone que defini no site.
Parece que ele considera mais coisas além do que realmente é.

Até foto de papel de parede mostrou como contendo stream.
Acho que não deve ser considerado tudo como sendo coisa pra apagar.

Talvez o próprio Windows crie algumas referências, por exemplo num aplicativo pra pegar os ícones, e isso seja considerado stream pelo programa.

Mistérios do Windows..... rs

[rmlazzari]

O que está em uso, não dá para apagar. No meu caso aqui, só não dá para apagar dois streams criados pelo antivirus...
O resto, apaguei e, como da primeira vez, aparentemente não fez a menor diferença. Mas como você diz, vai ver o Windows usa esses arquivos para indexações, coisas assim. Bem, nenhum dos arquivos que tinha streams anexados sumiu... Aqui é XP. Vou aguardar uns dias e ver seu o Windows os recria...

Abraço, Quintas, té mais!

[asimoes]

Pessoal,

Fiz um teste aqui para verificar o arquivo mem, baixei o programa alternatestremview, realmente o arquivo contém bytes diferentes de 0, embora o windows nos informe 0 bytes. Outra coisa faço o request hb_memio, na saída da rotina eu faço DbDrop("mem:apc01temp") e fazendo "refresh" no alternate o arquivo mem some. Então o harbour deve fazer a faxina do arquivo mem, usando a função dbdrop, então arquivo rodando em memória mesmo ainda é um sonho. aguém mais confirma?

[asimoes]

Não vejo muito problema nisso, se a função dbdrop elimina o temporário ainda vale apena usar.

[asimoes]

Outro questionamento e os indices criados usando TEMPORARY ou MEMORY é a mesma coisa?

[asimoes]

Outra, antes de fazer o dbdrop tem que fechar a área da tabela temporária.

[asimoes]

Fiz um teste assim:

cDriver:="DBFCDX"
DbCreate("mem:apc01temp", aStru, cDriver, .T., "apc01temp")

E não criou o arquivo mem, passando o driver DBFCDX

Alguém confirma isso, esse teste fiz no windows 10

Se não usar o REQUEST HB_MEMIO, o arquivo mem é criado na pasta.

[asimoes]

Outra informação sobre esse assunto:

O rdd padrão que eu estou usando é o leto e antes o dbcreate estava assim:

DbCreate("mem:apc01temp", aStru, , .T., "apc01temp") // assim criar o arquivo mem, mesmo usando o REQUEST HB_MEMIO

Alterei o DbCreate para:

DbCreate("mem:apc01temp", aStru, "DBFCDX", .T., "apc01temp") //assim o o arquivo mem não foi criado

E agora?

A impressão que eu tenho é que a tabela em "memória" funciona sem criar o arquivo mem ou stream, com os rdd´s padrão.

[JoséQuintas]

ASimões, não entendeu exatamente o problema:

O recurso do Harbour é pra criar um arquivo temporário na memória.
Se está no disco, é arquivo temporário em disco, não é em memória.
Se fosse pra criar em disco, nem precisava existir o recurso, então algo está errado aí.

[rmlazzari]

DbCreate("mem:apc01temp", aStru, "DBFCDX", .T., "apc01temp") //assim o o arquivo mem não foi criado

O mem não foi criado mas o "apc01temp" foi?

Aqui descobri que:

Código: Selecionar todos

dbcreate('mem:rollback.dbf',adbf)

Agora há dois arquivos no HD:

"mem", tamanho zero e visível e
":rollback.dbf:$DATA", 195 bytes e invisível

(Segundo o header(), o tamanho do cabeçalho de "rollback.dbf" é 194 bytes...)

Encho o arquivo de registros, o "alternatestremview" me mostra que o ":rollback.dbf:$DATA" realmente aumenta.

Saio do programa sem dbdrop() e o ":rollback.dbf:$DATA" continua lá, cheião.
Chamo de novo o programa (que se fosse um arquivo normal, ia dar pau, tentando recriar um arquivo que já existe), vou ver e
o ":rollback.dbf:$DATA" apenas sofreu um zap. Voltou a ter 195 bytes. E o "mem" continua lá, zerado.

Altero o programa, tiro o dbdrop() e coloco DELETE FILE MEM. Agora quando saio do programa some tudo. Tanto o "MEM" quanto o ":rollback.dbf:$DATA".

Altero de novo, tiro o DELETE FILE e deixo o dbdrop(). Na saída o ":rollback.dbf:$DATA" sumiu e o "mem" continua lá.

Decido então deixar apagando tudo:

Código: Selecionar todos

dbcommitall()
rollback->(dbclosearea())
dbdrop('mem:rollback')
dbcloseall()
delete file mem
set colo to
cls
quit

E agora a surpresa:

Mudo, de "mem" para "nem", tanto no dbcreate() quanto no "use", na dbdrop() e no DELETE FILE. E não é que funciona tudo direitinho?! Muda só o nome do arquivo de tamanho zero, que agora chama-se "nem", rs...

[asimoes]

Quintas,

Eu entendi perfeitamente o que está acontecendo, só que eu fiz um teste com o fonte que está na pasta contrib\hbmemio\tests\test.prg

É só pegar o fonte de lá compilar e ver o resultado, pelo menos aqui comigo não gerou o arquivo mem

Aguardo o retorno de vocês.

Obs.: procurei também com o alternatestream