PC Toledo

Hoje no harbour-users me responderam sobre isso.
É sobre o problema de pegar o ADO ao contrário: linhas/registros ao invés de registros/linhas

No changelog

2017-07-03 18:36 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* contrib/hbwin/olecore.c
! reverted order of indexes and dimensions in conversions of
multidimensional arrays.
This modification affects both conversions (1) from Harbour array
to OLE variant SafeArray and (2) from OLE variant SafeArray to Harbour
array. The first one is new Harbour extension of __oleVariantNew() so
here above modification should not create any backward compatibility
problems but the second interacts with code which existed in Harbour
from early OLE implementation so if someone already encoded hacks
to revert array indexes and dimensions at .prg level then now he has
to remove it.
Please not that above modification affects only for multidimensional
OLE typed arrays. It does not change anything for single dimension
arrays or single dimension arrays of variants which contains other
similar arrays in their items.

email sobre a questão

https://groups.google.com/forum/#!topic ... VESjqd00uo

A diferença é pegar direto do ADO, sem precisar ficar fazendo processamento pra corrigir o array.

E também... se atualizar o Harbour, a ordem já é certa, então a rotina existente pode estragar a ordem ao invés de corrigir.

JoséQuintas escreveu:E também... se atualizar o Harbour, a ordem já é certa, então a rotina existente pode estragar a ordem ao invés de corrigir.

Não sei se expliquei direito:
O retorno do Harbour era errado, antes dessa data, então, alguns fizeram rotina pra fazer a inversão.
Depois desta data o Harbour passou a fazer certo, e a rotina de inversão obrigatoriamente vai precisar ser removida.

Isso afeta tudo de OLE: ADO, Excel, etc. ao trabalhar com arrays multidimensionais.

Com certeza, transferir milhares de valores por um único array é muito mais rápido do que transferir um valor de cada vez.

Confirmei isso no Harbour 3.2 e Harbour 3.4, os dois foram corrigidos, porque a alteração foi antes do 3.4 ser congelado.

Confesso que voei nessa, tem algum exemplo pra explicar

Acabei indicando o browse, porque é onde convertem pra usar o browse da hwgui pra array.

Código: Selecionar todos

oRs := conexao:Execute( "...." )
oArray := oRs;GetRows()

ou no Excel, pra ler/gravar um bloco.

Ao invés de considerar:

{ 1, "jose" }
{ 2, "maria" }
{ 3, "cunha" }

retornava

{ 1, 2, 3 }
{ "jose", "maria", "cunha" }

Uma inversão de linhas/colunas.
Deveria retornar um registro por linha, mas retornava um campo por linha.

Ola!
Hummm, "miôrô" o entendimento pra nois!

Saudações,
Itamar M. Lins Jr.

E vale pra Excel.

Por exemplo, transferir o array do hbmysql para o Excel de uma vez só... antes dava problema.
Ou importar dados do Excel, ou qualquer coisa em OLE.

O detalhe importante também é que vai ser em ordem diferente, se a versão do Harbour for anterior ou posterior à modificação/correção.
Pode acabar parecendo que surgiu um bug ao atualizar o Harbour, quando na verdade antes é que estava com bug.....

Pode ser bom pra conferir se o Harbour continua com o problema ou não, ou no XHarbour... sei lá o que acontece nele.

Não conhecia esse método GetRows.

Fiz um teste aqui no meu sistema, harbour 3.4

Fiz um ValToPrg para um arquivo o resultado foi esse:

No meu select:

cQuery := "SELECT "
cQuery += " APC.N_CLASSE CLASSE, RES.TOTAL, APC.CLASSE CLASSEPG "

Código: Selecionar todos

M->__ValToPrg_Array := Array(3)
   M->__ValToPrg_Array[1] := Array(5)
      M->__ValToPrg_Array[1][1] := "1 A 3 SALÁRIOS MINIMOS"
      M->__ValToPrg_Array[1][2] := "1 SALÁRIO MINIMO"
      M->__ValToPrg_Array[1][3] := "ACIMA DE 3 SALÁRIOS"
      M->__ValToPrg_Array[1][4] := "ASSOCIADOS 01-A"
      M->__ValToPrg_Array[1][5] := "ASSOCIADOS 05"

   M->__ValToPrg_Array[2] := Array(5)
      M->__ValToPrg_Array[2][1] := 8.00
      M->__ValToPrg_Array[2][2] := 22.00
      M->__ValToPrg_Array[2][3] := 21.00
      M->__ValToPrg_Array[2][4] := 1.00
      M->__ValToPrg_Array[2][5] := 17.00

   M->__ValToPrg_Array[3] := Array(5)
      M->__ValToPrg_Array[3][1] := "02C"
      M->__ValToPrg_Array[3][2] := "03C"
      M->__ValToPrg_Array[3][3] := "01C"
      M->__ValToPrg_Array[3][4] := "01A"
      M->__ValToPrg_Array[3][5] := "05B"

O Harbour 3.4, apesar de ter o commit, tá fazendo errado.

Código: Selecionar todos

PROCEDURE Main

   LOCAL oExcel, oRs, aRowList, aColList, xCol

   SetMode(25,80)
   CLS
   oExcel := ExcelConnection( "d:\temp\test.xls" )
   oExcel:Open()
   oRs := oExcel:Execute( "SELECT * FROM [planilha1$]" )
   aRowList := oRs:GetRows()
   oRs:Close()
   oExcel:Close()
   FOR EACH aColList IN aRowList
      ?
      FOR EACH xCol IN aColList
         ?? xCol
         ?? Space(3)
      NEXT
   NEXT

   Inkey(0)

   RETURN

Quintas, na 3.2 tá funcionando isso?
Como a 3.4 tá congelada, não vai dar pra usar o método.

asimoes escreveu:Quintas, na 3.2 tá funcionando isso?
Como a 3.4 tá congelada, não vai dar pra usar o método.

Fui tentar atualizar isso no 3.4, começando por copiar olecore.c....

Agora fud.eu tudo.
Fui resetar a pasta do Harbour 3.4 resetei meus fontes pra dia 08.

Só pra dar uma idéia....
Se liberar versão agora, todo mundo que tenha atualizado antes, vai perder tudo de contabilidade.

Se for só isso, ainda tá bom, porque o backup recupera, o problema é... e o que mais perdi?

Não adianta nada ter os fontes do Harbour.
Se uma simples cópia do 3.2 para o 3.4 com alterações prontas, já é difícil, quanto mais alterar o que não tem.

Não dá certo copiar porque:
Tem declaração nova nesse fonte, que vém de arquivo include .h.
Essa mesma declaração passou a ser usada em outros fontes do núcleo/core.
Trocar todos esses fontes... não ajudou em nada.
Então resetei de volta ao que estava antes.

Mas .... fiz na pasta dos meus fontes, que não estava salvando, e fud.eu tudo.

Ainda contando até 10, antes de fazer sei lá o que....

Quintas que M!

baixei a ultima atualizacao da 3.2 , mas esta dando erro no LIBPNG.a nao deu para tastar
alguem teria uma libpng.a sem problemas para W10

Só pra corrigir minha informação:

O 3.4 NÃO tem essa atualização, ele parou antes.
É que confundi as datas, porque o meu tem pequenas modificações com data posterior.

Acho que só um master pra atualizar o 3.4.

Tem essa alteração do array, e aqueles limites mostruosos de variáveis, que seriam interessantes pra acrescentar.

Entre perder o que foi melhorado, e perder isso, por enquanto dá pra mim ficar sem isso, e prefiro assim.

Quanto à LIB PNG.... será que essa não seria compatível com a 3.4 e seria só copiar?

JoséQuintas escreveu:Só pra corrigir minha informação:
O 3.4 NÃO tem essa atualização, ele parou antes.
É que confundi as datas, porque o meu tem pequenas modificações com data posterior.

Corrigindo a correção kkkkk

O Viktor parou de atualizar o 3.4 em dezembro/2017 e essa mudança foi em julho/2017.
Ela consta como fazendo parte do 3.4, inclusive está no changelog do 3.4 e nos commits.

Aí complicou mais ainda.
Se até o Viktor aparentemente falhou na atualização do 3.4....
Sem chance pra nós...

Ainda resta uma última tentativa: retornar o mingw para a última versão "testada" pelo Harbour, a 7.1
Pode ser uma possibilidade, afinal, não chegou a ser testado com mingw 8.1.

fiz o teste pegando a LIBPNG.a da versao 3.4 e da versao 3.2 64 e da antiga 3.2 e nenhuma funcionou com a versao nova da 3.2

PC Toledo

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array

Browse ADO/Array