Conflito entre Harbour e tbrowse.prg externo

[Itamar M. Lins Jr.]

Olá!
AdUserClient Significa usar a DLL que vem no cliente, para ajustar isso.

Código: Selecionar todos

In MySQL, a server-side cursor is materialized into an internal temporary table. Initially, this is a MEMORY table, but is converted to a MyISAM table when its size exceeds the minimum value of the max_heap_table_size and tmp_table_size system variables. The same restrictions apply to internal temporary tables created to hold the result set for a cursor as for other uses of internal temporary tables. See Section 8.4.4, “Internal Temporary Table Use in MySQL”. One limitation of the implementation is that for a large result set, retrieving its rows through a cursor might be slow.

Parece que é 16 Megas o tamanho padrão da tabela temporária do lado do servidor.
Falta saber o cache do lado cliente.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

AdUserClient Significa usar a DLL que vem no cliente, para ajustar isso.

Não.
adUseServer - o cursor, o arquivo temporário, fica no servidor
adUseClient - o cursor, o arquivo temporário, fica no terminal

Justamente por adUseServer ficar no servidor, tem isso do cache, e de puxar aos poucos, etc.
A vantagem do adUseServer seria pra tabelas gigantes, assim não precisa trazer tudo de uma vez.

É só fazer um SELECT * de uma tabela gigante, e vai ver como demora ao usar adUseClient, porque vém tudo de uma vez, mesmo se forem gigabytes.

Aliás... na minha rotina de backup, isso ficou bem visível, porque o backup usa tudo.
Demora muito se eu fizer select *, o tempo de trazer tudo.
E por isso faço por intervalos.

[Itamar M. Lins Jr.]

Olá!
Rapaz!

Just a final question: "Query execution is always 100% at the server"

Depois eu leio mais... Mas não é assim não.
Existe 2 cursores um no cliente e outro no servidor, isso já ficou claro.
Ou vc não entendeu isso ainda.

AdUseClient o CacheSize é ajustado pela LIB e não por padrão que serie o ADO e é 1

O objeto Recordset da ADO possui a propriedade CursorLocation que pode ter dois valores: adUseServer e adUseClient. O padrão assumido é adUseServer , com ele a performance é bem melhor , para base de dados locais. Para acesso a base de dados cliente-Servidor , tipo SQL-Server, o valor adUseClient apresenta melhor resultado.

CacheSize existe independente da escolha adUseClient ou adUseServer.
Quando o Cursor é do lado cliente isso não significa que não existe o cursor do lado do servidor, apenas diz que "teoricamente" o RS que veio foi transportado p/ o lado cliente mas que existe um cursor do lado do servidor lendo e mandado p/ o lado cliente se for menor que 16megas que é o padrão do Mysql ok.

Saudações,
Itamar M. Lins Jr.

[sygecom]

Zé,
Por mais que esteja tudo local, ainda assim passa pela rede.
Faça um teste simples, desative a placa de rede e tente conectar localhost, no SGBD e vai ver que não da conexão.

Então imagina que algum servidor/roteador está gerando os endereço IP, e são protocolos TCP que algum momento podem falhar com alto trafego e etc.. e ter uma resposta errada caindo o sistema.

Erro comum que vejo em clientes, é trafegar as câmeras(dvr) de monitoramento na mesma rede do sistemas, isso torna um trafego tão grande que causa erros no sistema por competir o trafego na rede com altos volumes de vídeos em tempo real trafegando, apensar de não ser seu erro relatado, mas imagino que no dia a dia, você deve ter clientes também com esse mesmo cenário.

[JoséQuintas]

Just a final question: "Query execution is always 100% at the server"

Não entendi.
Alguém achava que os comandos SQL eram executados em outro lugar?

[JoséQuintas]

It seems to me that setting CacheSize will have no effect for a client-side cursor, because the records are already in local memory. But I can't find any official documentation that explicitly says this.

https://stackoverflow.com/questions/666 ... ide-cursor

À primeira vista, não se encontra documentação oficial confirmando isso ou não, apenas é presumido que fica tudo na memória do terminal e por isso não tem conexão com servidor.

[JoséQuintas]

adOpenStatic Abre um cursor do tipo static.(Cópia estática de um conjunto de registros)

que eu saiba, cópia estática, é uma cópia completa, sem dependências.
igual no Harbour, na compilação -fullstatic

[JoséQuintas]

Se eu tiver tempo faço alguns testes "diferentes".

[JoséQuintas]

Error on 15/08/21 10:29:00
EXE Name; D:\fontes\integra\jpa.exe
JPA: 2021.08.14.2118
Login JPA: JOSEQ
Alias:
Folder: d:\dados\sistemas\
Windows: Windows 10 10.0
Computer Name: JOSEJPA
Windows User: jmcqu
Logon Server: \JOSEJPA
User Domain: JOSEJPA
Harbour: Harbour 3.4.0dev (826a21f886) (2021-06-08 00:29)
Compiler: MinGW GNU C 10.3 (32-bit)
GT: WVG

SYSTEM ERROR
Error BASE/1081 Argument error: +
Called from SETCOLORTBROWSE(72)
Called from TOBROWSE(858)
Called from BROWSEADORC(36)
Called from BROWSEADO(203)
Called from JPSITECLASS:GRIDSELECTION(42)
Called from PESQUISA(197)
Called from (b)APPINITSETS(46)
Called from GETDOSETKEY(467)
Called from GETAPPLYKEY(210)
Called from GETREADER(168)
Called from READMODAL(113)
Called from JPSITECLASS:ESPECIFICO(60)
Called from JPSITECLASS:EXECUTE(395)
Called from PSITEJPA(13)
Called from DO(0)
Called from DOPRG(145)
Called from (b)RUNMODULE(110)

Acabou de acontecer na minha máquina.
Já tentei várias vezes causar o problema de novo, mas não consegui.

[JoséQuintas]

O que eu estava fazendo:

Essa é uma opção pra alterar diretamente meu site, então a base está na internet.
Passeei alguns registros pra frente e para trás, e acionei a pesquisa (o browse).
Deu esse erro.

Repeti a operação várias vezes, SAINDO OU NÃO do aplicativo, e o erro NÃO aconteceu de novo.

Lembrando: uso multithread, então mesmo que o módulo dê erro, o aplicativo não fecha.

É uma situação curiosa.
Passear pelos registros significa estar usando a conexão.
F9 para o browse usa a conexão que já está aberta.

Difícil pensar no motivo de ter falhado uma vez.

[JoséQuintas]

Só comentário extra:

Neste MEU caso, NÃO é a conexão MySQL local de comentários anteriores.
Mas é erro como se o objeto browse tivesse desaparecido.
Erro em disco ou em conexão, não deveria ser motivo pra destruir o objeto tbrowse.
Se for assim, é um grande bug no Harbour.

Aliás..... está sendo na CRIAÇÃO DO BROWSE, nem começou a ser usado.

[JoséQuintas]

Deu erro nesta linha, somando string.

que é chamada aqui

que é chamada aqui

Está criando o browse, nem começou a usar.

[JoséQuintas]

Só comentário:

A linha em ToBrowse() não bate, porque como uma tentativa, acabei de mover de um fonte pra outro.
Movi de ze_browseDBF() pra ze_browseADO(), só pra ficar junto e ver se faz diferença.

Desta vez é em máquina normal, uso normal, NADA de terminal service.
Então... terminal service removido das possibilidades.

[JoséQuintas]

Se acham que isso de uma função chamar outra é problema....

TBrowseDB() chama TBrowseNew() que chama a classe TBrowse():New()

O detalhe a mais é que esse fonte tá no meu aplicativo, não sei como fica o original do Harbour.
E acho estranho essas funções estarem no meio da classe tbrowse.

[JoséQuintas]

O que encontrei de diferente agora:

Código: Selecionar todos

/* HB_BRW_STATICMOUSE controls if mouse position is static
* and set by call to HitTest() method or dynamic calculated
* by calls to MPOS() / MCol(). CL53 uses dynamic mouse but
* I guess that some Harbour GUI libraries inherit from TBrowse
* and because they do not support MCol()/MRow() (when someone
* will create GUI library integrated with GT system?) then they
* need static mouse with positions passed by GUI code. [druzus]
*/
/* #define HB_BRW_STATICMOUSE */

Não entendi nada disso.
Mas imagino que possa dispensar meu tratamento de mouse, ou possa estar em conflito, não sei se é possível.
E não sei se causaria o erro em questão.