PC Toledo

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

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.

Itamar M. Lins Jr. escreveu: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.

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.

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.

Itamar M. Lins Jr. escreveu: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?

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.

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

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

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.

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.

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.

Deu erro nesta linha, somando string.

que é chamada aqui

que é chamada aqui

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

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.

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.

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.

PC Toledo

Conflito entre Harbour e tbrowse.prg externo

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????

Harbour maluco ????