Importar dados Postgres 9.6 usando PGSQL 10.X

[Itamar M. Lins Jr.]

Olá!
Estou aqui, lendo e quebrando a cabeça para aprender instalar importar e acessar tabelas do Postgres.
Tentando com SQLMIX primeiro.
O arquivo tem mais de 1 giga(backup.sql), cheio de lixo. Não adianta usar SQL se não sabe cortar tráfego de rede. Para quê tanta porcaria dentro da base de dados ? Armazenar tabelas alteradas, tudo que é incluído e alterado e outras tarefas sem importância, não tem rede que aguente.


Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!

Código: Selecionar todos

C:\dev\hb32-code\contrib\sddpg>hbmk2 sddpg.hbp ..\rddsql\rddsql.hbc
hbmk2: Processando opções do ambiente: -comp=mingw
hbmk2: Dependência 'pgsql' encontrado: C:\Program Files\PostgreSQL\10\include
hbmk2: Encontrado COMF .lib com o mesmo nome, voltando a usá-la em vez da .dll
       .
hbmk2: Biblioteca de importação criada: liblibpq.a <= C:\Program
       Files\PostgreSQL\10\lib\libpq.dll
hbmk2: Compilando...
hbmk2: Criando biblioteca estáticas... libsddpg.a

Funcionou de primeira a criação da LIB! Só deu uns erros por conta da indicação rddsql.hbc que precisa.
Usando o Harbour 3.2! GCC

Código: Selecionar todos

C:\dev\hb32-code\contrib\sddpg>harbour -build
Harbour 3.2.0dev (r2104281802)
Copyright (c) 1999-2021, https://harbour.github.io/

Harbour Build Info
---------------------------
Version: Harbour 3.2.0dev (r2104281802)
Compiler: MinGW GNU C 10.3 (32-bit)
Platform: Windows 10 10.0
PCode version: 0.3
ChangeLog last entry: 2021-04-28 20:02 UTC+0200 Aleksander Czajczynski (hb fki.pl)
ChangeLog ID: 4643587824552fd877e7f02ad11596e0b30c465d
Built on: Aug 26 2021 19:25:25
Build options: (Clipper 5.3b) (Clipper 5.x undoc)
---------------------------

C:\dev\hb32-code\contrib\sddpg>

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
Bati cabeça aqui, umas horas, depois lembrei de 64/32 bits!
Removi tudo, instalei Postgres 10 32 Bits e funcionou de prima!
Muito rápido mesmo o negócio! Foguete!

O problema foi que compilei o Harbour para 32Bits, e o Postgres instalei p/ 64 Bits, resultado fazia tudo sem erro, mas linkava a LIBLIBPQ.A e não achava as funções.
Importava na unha sem erros etc... mas não achava as funções pqxxx depois de linkados...

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
String p/ conexão:

Código: Selecionar todos

IF rddInfo( RDDI_CONNECT, { "POSTGRESQL","localhost","postgres","naodigo","basedados","5432"}) == 0
      ? "Could not connect to the server"
      RETURN
   ENDIF

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
Precisa da libpq.dll junto do exe ou no PATH.
Não sei pq não funciona -fullstatic e static (não fazem efeito)

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Não sei pq não funciona -fullstatic e static (não fazem efeito)

A lib NÃO substitui a DLL, ela apenas tem as rotinas intermediárias pra usar a DLL.
Pra ser fullstatic, precisaria ter os FONTES pra entrarem no lugar da LIB.
Como ninguém iria dar manutenção em fontes... a opção de DLL é a mais viável.

O mesmo com MySQL, que tem fontes pra serem usados com C, no MySQL original, mas não são usados.

E isso significa que pode chegar uma hora, que nem a LIB do Harbour vai funcionar mais, com DLLs mais novas que não sejam compatíveis internamente.

Só recapitulando:

1)
O utilitário IMPLIB (ou algo assim), ele gera uma LIB pra uso da DLL.
Digamos que seja aquilo que a gente costuma fazer: CallDll( .... ).
UMA das LIBs apenas substitui essas declarações.

2)
Apenas isso não é suficiente, porque tem muito mais tipos em linguagem C do que em Harbour.
A LIB do Harbour é outra intermediária, que converte os tipos pra ficarem compatíveis com as chamadas.

Se quiser, pode comparar com a classe que fiz pra RMCHART.
Nela tem as funções ToDouble(), ToInt(), etc. pra converter os números para o formato das funções do RMChart.
E também tem as CallDll() pra acessar a DLL.

Código: Selecionar todos

   METHOD AddDataAxis(a,b,c,d,e, ... )     INLINE ::CallDllStd( "RMC_ADDDATAAXIS", a, b, c, ::ToDecimal( d ), ::ToDecimal( e ), ... )
   METHOD AddGrid( ... )                   INLINE ::CallDllStd( "RMC_ADDGRID", ... )
   METHOD AddGridLessSeries(a,b,c,d,e,...) INLINE ::CallDllStd( "RMC_ADDGRIDLESSSERIES", a, b, ::ToDouble( c ), d, ::ToLong( e ), ... )
   METHOD AddHightLowSeries(a,b,c,...)     INLINE ::CallDllStd( "RMC_ADDHIGHTLOWSERIES", a, b, ::ToDouble( c ), ... )
   METHOD CallDllStd( cName, ... )         INLINE hb_DynCall( { cName, ::hDLL, HB_DYN_CALLCONV_STDCALL }, ... )
   METHOD ToDecimal( xValue )              INLINE xValue + 1.01 - 1.01
   METHOD ToDouble( xValue )
   METHOD ToLong( xValue )

Aí dá pra ver que tem o CallDll() pra cada função do RMChart, isso é o que o IMPORTLIB faria, geraria uma LIB com essas declarações, PRA USAR A DLL.

Mesmo assim, ainda faltaria a conversão conforme o tipo de parâmetro, que nesse caso usei ToDouble(), ToLong(), ToDecimal(), etc.
Isso é o que a lib do Harbour faz.

Então acabam sendo 2 LIBs e mais a DLL: uma lib só com declarações de funções, e outra pra converter direito cada parâmetro
E... não substitui a DLL, porque é justamente pra usar a DLL.

Minha classe pra RMCHART acabou fazendo o papel do que seriam essas duas LIBs: declarou as funções da DLL, e converte conforme parâmetros.
E isso não substituiu a DLL do RMChart, apenas permite usar a DLL.

Só comparei com a classe do RMChart como forma de ficar mais fácil de entender.
Não sou nenhum expert nessas coisas, mas no caso do RMChart tentei e deu certo.

[Itamar M. Lins Jr.]

Olá!

E isso significa que pode chegar uma hora, que nem a LIB do Harbour vai funcionar mais, com DLLs mais novas que não sejam compatíveis internamente.

O pessoal usando CLIPPER e XP (AINDA!) Quando chegar esse dia será no ano 3000 TALVEZ!

Saudações,
Itamar M. Lins Jr.