RDD LETO Sem Mistério

[alaminojunior]

Mario, não sei se já tomou uma decisão, mas pondere a respeito de usar a SQLRDD. Aliás, me perdoem os moderadores por 'desviar' o foco da thread, mas notei um leve sofrimento no semblante do colega.

Minha 'pouca' experiência na questão é a seguinte:

LetoDB, deixei rodando algum tempo em produção num cliente, porém tive sérios problemas com Set Scope e algumas rotinas onde precisa gerar códigos de pedidos. Quando DBFCDX funcionava 200%, e ao migrar para LetoDB, infelizmente não deu certo. Talvez tenham corrigido tais defeitos.

Netio, não conheço.

SQLRDD, foi a qual adotei há dois anos com ajuda do Mestre Leonardo Machado, e uso até hoje.
Motivos principais:
1º Me permitiu usar a mesma sintaxe DBFCDX até me sentir em casa com ela;
2º Depois de acostumado, só uso sintaxe SQL em rotinas novas, mantendo sintaxe DBFCDX em rotinas à atualizar;
3º Trabalhar com bancos SQL abre inúmeros horizontes, tornando possível a criação dos mais diversos relatórios gerenciais e administrativos, por exemplo;
4º Torna fácil a conexão com bases remotas, abrindo mais alguns horizontes.

Basta compilar seus projetos com as lib´s da SQLRDD, ter o servidor MySQL ou PostGres instalado no servidor, um arquivo .ini nos clientes informando os parâmetros de conexão e somente isso.

[alberto_dias]

Prezado AlaminoJunior
===================
Primeiramente, a possibilidade de usar SQL nos projetos é maravilhosa,( excelente para todos nós que usamos DBFCDX), :)Pos
"Usei muito no tempo do FOXPRO 2.5 e era uma ferramenta PODEROSA, PRÁTICA E RÁPIDA para se usar com o Banco de Dados DBFCDX"
Estou trocando gradualmente os meus clientes para o LETO, estou sem problemas no momento, não uso o SET SCOPE.
Faço isso pois tive vários problemas, principalmente quando em rede, com as novas máquinas que estão chegando são de 64 bits,
e quando colocava em rede com as máquinas que já existiam de 32 Bits, ai o bicho pegava, os CDX quebravam e eu não conseguia nem dormir. :?
Novamente agradeço ao este Grupo, me ajudou em muito, troquei os clientes para o Leto e consegui dormir de novo, Obrigado, :-Y
Estou aqui lendo sua mensagem e gostaria de perguntar, pois a possibilidade de usar SQL daria uma grande força para o meu trabalho,
e para muitos que estão lendo estas mensagens, pois poder usar o SQL, abre grandes Horizontes.( Meu pode acreditar).
============================================================================================
SE PUDER RESPONDER,
============================================================================================
1-) Roda junto com estruturas diferentes 64 bits X 32 bits ? ("O Leto possibilitou isso e não degrada os CDX")
2-) Como fica o trafego na Rede ? ("O Leto deixou as estações rápidas")
3-) Tem algum comando que não funciona ? ("No leto não consigo usar LetoFile()")
4-) Precisa mudar muito os Prgs atuais ? ("No leto foi muito fácil, quase nada mudou")
5-) Uso Harbour 3.0 + Bcc 5.8.2 + Gtwvg + Leto, será que tem algum Problema ao usar junto com o RDDSQL ?
============================================================================================
ALBERTO DIAS :D

[alaminojunior]

1. Roda perfeitamente. Tenho clientes usando terminais com 32 e/ou 64 bits e até o momento está perfeito.
Inclusive ultimamente, quando preciso formatar ou dar alguma manutenção em servidores, tenho optado por instalar a versão 64bits do MySQL (quando o hardware permite, claro), aí sim a coisa fica boa.

2. A princípio você vai notar um ligeiro ganho de velocidade, eu disse ligeiro. No item 4 explico o porquê.

3. Não tenho notado.

4. A princípio, assim como no LetoDB, precisa colocar o trecho responsável pela conexão com o banco.
Feito isso, o seu sistema rodará da mesma forma como rodava antes.
Agora, para poder extrair algum poder a mais do banco SQL, é preciso (e recomendável) fazer uso de instruções SQL.
Com o auxílio de um bom cliente SQL como o HeidiSQL, vá criando e testando suas query´s com calma. Com isso, a sua experiência vai aumentando e você irá tirar ótimos resultados.

5. O primeiro entrave é que SQLRDD não funciona com Harbour.
Eu utilizo xHarbour 1.2.3 + BCC 6.40, e para a parte gráfica GTWVG e HWGUI. Mas é possível trabalhar com ambas as RDD´s. Basta indicar a padrão que será usada na abertura das tabelas, e depois para abrir tabelas específicas, use a cláusula 'VIA' do comando de abertura, indicando a RDD a utilizar.

[Itamar M. Lins Jr.]

...porém tive sérios problemas com Set Scope e algumas rotinas onde precisa gerar códigos de pedidos.

Uso o SET SCOPE o tempo todo, e não me deu problema, tenho mais de 5 contadores, pedidos, NFe, Orçamento, OS, etc... todos funcionando sem problemas.

PS. Recomendar o uso do xHarbour neste momento, penso que não é uma coisa boa, tem uma serie de problemas já resolvidos no Harbour.
Outra coisa é comparar DBF com SQL, não tem nada haver e o LETODB não é uma ferramenta comercial.
Na minha opnião se for mudar para SQL irei usar o SQLMIX do Harbour que é gratuito e realmente estarei usando uma coisa moderna, o SQLRDD é um simulador.
Quanto está custando o SQLRDD ?

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Exemplo de indice temporário via LETODB e Hwgui.

   cQuery := " dtos(vencimento) >= '"+dtos(inicio)+"' .and. dtos(vencimento) <= '"+dtos(fim)+"' .and. empty(pagamento) .and. '"+cVenda+"' == cod_venda"
  OrdBy  := "dtos(vencimento) + cod_client "

If lRddLeto
   Index on &OrdBy Tag re99 to &cTemp  for &cQuery temporary
Else
   tRec   := re->(OrdKeyCount())
   oBar   := HProgressBar():NewBox( "Processando, "+lTrim(str(nRec,9))+" De "+lTrim(str(tRec,9))+" Registro(s)",,,400,, 5,tRec,,.T. )
   Index on &OrdBy Tag re99 to cTemp for &cQuery temporary eval {||oBar:Step(),.t.}
   oBar:Close()
EndIf

Desliguei o barra de progresso quando uso o LETODB.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Ola!
Usando CDX Harbour 3.2 Letodb ou CDX.

************************************************
Function FiltraPorEquivalencia(cStrFiltro,oBPes)
************************************************
*
*
Local aFiltro := {}, oDlg, Titulo := "Filtrando: "+ cStrFiltro, oFont,oBrw, nReg, lAcao := .T.
If empty(cStrFiltro)
   hwg_Msgexclamation("Digite algo !")
   return .t.
EndIf

cStrFiltro := alltrim(cStrFiltro)
eq->(OrdSetFocus(2))
el->(OrdSetFocus(1))
el->(OrdScope(0,nil))
el->(OrdScope(1,nil))
el->(DbGoTop())
Do While el->(OrdWildSeek( "*"+cStrFiltro+"*", .t. ))
   If eq->(DbSeek(el->cod_mercad))
      AAdd( aFiltro, {eq->cod_mercad,eq->mercadoria,eq->avista,eq->quantidade} )
   EndIf
EndDo
nReg := len(aFiltro)

If nReg > 0

   PREPARE FONT oFont NAME "MS Sans Serif" WIDTH 0 HEIGHT -14

   INIT DIALOG oDlg CLIPPER NOEXIT TITLE Titulo Font oFont AT 0,0 SIZE 800,400  STYLE WS_VISIBLE+WS_SYSMENU+WS_CAPTION+DS_CENTER

   @ 5,05 Browse oBrw array of oDlg Size 780,380 Style WS_VSCROLL ;
   On Click {|| hwg_EndDialog() } ; //Tecla ENTER

   hwg_CREATEARLIST(oBrw,aFiltro)

   oBrw:aColumns[1]:heading := "Código"
   oBrw:aColumns[2]:heading := "Descrição"
   oBrw:aColumns[3]:heading := "Preço"
   oBrw:aColumns[4]:heading := "Quantidade"

   ACTIVATE DIALOG oDlg //NOMODAL
   If eq->(DbSeek(oBrw:aColumns[1]:Value))
      oBPes:Refresh()
      lESC := .F.
   Else
      hwg_Msginfo("Não achou")
      lAcao := .F.
   EndIf

Else
   hwg_Msginfo("Equivalência não encontrada !")
   oBPes:Refresh()
   lAcao := .F.
EndIf

Return lAcao

[Itamar M. Lins Jr.]

3-) Tem algum comando que não funciona ? ("No leto não consigo usar LetoFile()")

Aqui sempre funcionou, verificou esse "FLAG": ENABLEFILEFUNC = 1

*************************
Function ordena_planoctas
*************************
*
*
Local cFunc := iif(lRddLeto,"leto_file(dServidor+'planoctas.cdx')","file('planoctas.cdx')" )

If !&cFunc
   AbreDb('planoctas.dbf','pl',.f.)

   nReg := 0 ;  tReg := pl->(RecCount())
   oBar := HProgressBar():NewBox( "Criando indices planoctas, "+lTrim(str(nReg,9))+" De "+lTrim(str(tReg,9))+" Registro(s)",,0,400,, tReg, tReg,,.f. )

   index on reduzida tag pl01 eval {||oBar:Set(,Recno()),.t.}
   index on conta    tag pl02 eval {||oBar:Set(,Recno()),.t.}
   index on reduzida tag pl03 for tipo = 'A'  eval {||oBar:Set(,Recno()),.t.}
   index on nome     tag pl04 for tipo = 'A'  eval {||oBar:Set(,Recno()),.t.}
   FechaDb('pl')
   oBar:Close()

endif
RETURN Nil

//dServidor pode ser //locahost:2812/ ou //meuip.xyz.com.br:2812/ ou //192.168.1.1:2812/...
//O PATH do leto eu informo no arquivo letodb.ini

Port = 2812              
Logfile = "letodb.log"   
DEFAULT_DRIVER = CDX     
DATAPATH = c:\dados\xyz\
ENABLEFILEFUNC = 1
CRYPT_TRAFFIC = 0
PASS_FOR_LOGIN = 0
PASS_FOR_MANAGE = 0
PASS_FOR_DATA = 0
Share_Tables  = 0
[DATABASE]
DataPath = c:\dados\xyz\
Driver = CDX

Saudações,
Itamar M. Lins Jr.

[alaminojunior]

PS. Recomendar o uso do xHarbour neste momento, penso que não é uma coisa boa, tem uma serie de problemas já resolvidos no Harbour.

Itamar, leio isso quase que constantemente em fóruns e mais uma vez pergunto:
Que problemas são estes ?
Sei que MultiThread no xHarbour realmente tem os seus pepinos, mas tirando isso que aliás não uso ... quais são concretamente estes problemas ?

Até onde eu entendo e uso de xHarbour, funciona maravilhosamente bem. Pode ser que se um dia eu experimentar o Harbour, possa mudar de opinião, mas ...

[Itamar M. Lins Jr.]

On Sat, 19 Jan 2013, Andi Jahja wrote:

Hi Andi,

> Seems no comment at all, particularly from what ppl call *nix users. BTW,
> does anyone here have a thought about it?

I think that xHarbour lost most of them.

> FYI, we stuck releasing versions officially because there's no-one
> interested in building that *nix stuffs.

In the last year you made a lot to break *nix builds. Now after your
recent modifications you break them again so maybe few really advanced
users who are patient enough to fix your modifications can create *nix
xHarbour builds - others migrated to Harbour.

> I would suggest to leave *nix if there's no longer interest in it.
> Usability is much more important than what is called portability.
> Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS,
> so the rest 0.01% can be disregarded (read: not worthy)

Bad idea, it will only help to hide bugs which appeared recently in
xHarbour. Some of them can be exploited also on MS-Windows, i.e. custom
memcpy() broke all 64bit builds. Also WIN 64 ones though here xHarbour
applications GPFs when user address space reach 2^32. On serious platforms
such addresses are default at application startup just to catch such buggy
code ASAP and fix it. To be more funny advanced compilers make such
optimizations much better with optimized autoinlined code so it also
reduces the speed.

There are other serious development reasons to keep support for *nixes,
i.e. there is no tool like VALGRIND for MS-Windows so you won't be able
to catch some serious problems, i.e. I see that in last weeks you started
to fix memory leaks in xHarbour compiler code. But you haven't discovered
yet that it's not possible to make it well in classic way due to bison
behavior. Bison authors also saw this problem so they introduced
expression destructors which should help in such process. Anyhow these
functionality still does not work as expected in some cases what can be
well seen in valgrind logs and you want to drop support for platforms
were such important tool can be used. In practice it means that there is
very small chance that you will ever reach sufficient results in compiler
memory leak fixes.
BTW I've seen your message on xHarbour user list that such memory leaks are
only in compiler. It's not true. Memory leaks which appear due to wrong
syntax are usually caused by unreleased bison grammar expressions so they
exist also in macrocompiler and are runtime memory leaks which can be
exploited in all programs which macrocompile user expressions.
To resolve this problem in Harbour few years ago I created garbage collector
for expressions. To not hide other memory leaks in compiler mode it's
activated on syntax errors only. This job is still before you and you want
to drop support for platform were important helper tools can be used.
Finally it means that you want to drop support for platforms which begins
to be the most popular one on the all world used in most "smart" devices
so it will be very important signal about xHarbour future for users.

> We should not stop because of it.

IMHO before new release you should fix some critical problems introduced
in last months.
Porting some things from Harbour you made few typos which later have
unpredictable results, i.e. typo in really small patch which fixed very
slow source code browsing in debugger caused that Luiz (who wrongly check
that the problem was fixed in Harbour) used in xHarbour debugger RTL
classes so now it's not possible to debug them or even use debugger by
users who overloaded some part of RTL classes used in debugger.
Your "improvements" in macro compiler speed caused that now maximum
macrocompiler string size is 8191 bytes in xHarbour. Before your
modifications it was ~32768 and longer strings could cause unpredictible
results (memory corruption) due to bugs in HVM part of macro compiler
code. In Harbour all such bugs have been fixed long time ago and it's
guarantied that Harbour can compile any macro expression up to 16MB and
if longer expressions cannot be compiled then it's guarantied that clean
RT error is generated without any hidden memory corruption. And to compare
Harbour macro compiler is about 3 times faster then xHarbour ones and is
fully reentrant safe so it does not need and MT locks. The whole MT mode
in xHarbour is sth what should be rewritten from scratch. Now number of
MT applications in [x]Harbour community is growing up and they have to
be compiled by Harbour because xHarbour MT mode is unusable for code which
needs stability and some more advanced MT functionality. Good example is
LETO server which cannot be compiled by xHarbour due to critical xHarbour
bugs, missing functionality and wrong MT model.
There are also other problems introduced recently like wrong casting which
pacified warnings when in fact they were bugs exploited in 64bit mode. Now
it's horrible job to clean xHarbour code and make it fully functional for
Win64 bit mode - you hide the most helpful thing: compiler warnings so
you will have to find someone who will check whole xHarbour code line by
line and fix all related code. Of course at the beginning he should have
clear vision what should be done and which types should be used. I do not
thing it's possible to realize it in resonable time so this should not
stop you anyhow I signal serious problem.

I'll only add that you may have problems with code copied from Harbour.
xHarbour GC does not support custom user mark functions so you should
expect random memory corruptions after GC activation. Very hard to
locate and fix problems. Unlike Harbour xHarobur does not detect them
automatically so it will cause random GPFs in different subsystems.
User will report them but fixing such things using information from
users is like fighting with a ghosts so I strongly suggest to do sth
with it.

best regards,
Przemek

[Itamar M. Lins Jr.]

Correção na função do xHarbour para o Harbour poder roda o SQLRDD.

I've just committed it:

2013-01-21 16:36 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* harbour/src/rtl/itemseri.c
+ added support for deserialization xHarbour HB_SERIALIZE() output.
All types except codeblocks are supported. I haven't added support
for xHarbour serialized data with cyclic references. If it will be
really necessary then I can implement it.
I also added workaround for bug in xHarbour serialization code so
now Harbour correctly decodes data with LONGLONG numbers though
xHarbour cannot correctly decode its own stream.
Now Harbour can deserialize xHarbour data encoded by HB_SERIALIZE()
and stored somewhere. It can be important in migration process, i.e.
SQLRDD uses HB_SERIALIZE() to encode data in memos so now SQLRDD
port for Harbour should read old tables and decode xHarbour items
correctly. The same is for any other tool which saved HB_SERIALIZE()
output in xHarbour.

best regards,
Przemek

[Itamar M. Lins Jr.]

Vale lembrar que depois desse post ai em cima o Andi, deixou o projeto do xharbour.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Tem muita coisa.
Para um simples usuário como eu pode não significar nada porém para o pessoal que desenvolve aplicações comerciais do porte do Xailer,FiveWin, ADS, etc... é muito importante essas correções.
Além do mais quem é a equipe do xHarbour neste momento ?
Já ouviu falar no QT ? Verificou o que o Pritipal tem feito, os exemplos ?

On Mon, 28 Jan 2013, Ron Pinkas wrote:

Hi,

Sorry for late respone.

>> Please only remember that I was not alone in Harbour modifications in
>> last years. Viktor made really great job in general code and used types
>> cleanup. Mindaugas added important extensions to compiler and HVM/RTL
>> code, Pritapl is extensively working on set of addons like HBIDE, HBQT,
>> HBXBPP. Also many other people worked on Harbour.
> Thanks for your modesty, but I am convinced that none of this would
> ever take place, unless you first revived Harbour, single handedly,
> as you did, and even after, those IMO, are minor, and superficial
> contributions, compared to your work.

Thanks for nice words but it's not really true. I think that
people using HBMK2 found Viktor modifications as the most
important ones because they allow him to easy move to Harbour
and without any doubts such basic functionality is the most
important for them so for sure it was extremely important for
the whole project.
Anyhow I'm most interested in the future of both projects
so lets leave this discussion. I feel that I can hurt someone
continuing it, i.e it was not my intention to discard Andi
work. I only wanted to point that some not working ports may
create false imaginations about real functionality of original
code and competitions of its authors. I hope that Andi seriously
rethink his decision because I'm finding him as the very important
person in the future modifications.

>> In Harobur there is text filewhere I tried to discribe main differences
>> between both projects:
>> http://http://harbour-project.svn.sourc ... t?view=log
>> This may show you what should be done. I'll try to update this file
>> and add some information about other differences.
>> As you can seen not too much. I think that in less then month all
>> modifications can be finished.
> Actually this is not shocking for me, and I was debating it my self.
> I am not sure what would be easier, as it mostly depends on the
> DRIVE of the specific individual[s] interested in caring this task.
> Sadly, I am not in a position to volunteer for this Job, for many
> personal reasons, so I can not suggest what would be easier. I trust
> that the person willing to take on this Job, will have his
> preference.

The most important differences between both project are well known.
Anyhow it's also something that it was not very popular in news list
but it's very important for general language description in the future:
small incompatibilities to Clipper and anomalies in implementation
(also in Clipper) which where cleaned or at least documented in
Harbour. We do not have to follow exactly some decisions anyhow
it's much easier to operate on code where some problems are resolved
even to add again some extensions because programmer can see some
interactions which were unknown for him in initial implementation.
It also allows to eliminate duplicated code or code which is to
danger and may break HVM code.
Good example is OOP implementation. Many of __cls*() and __obj*()
functions are repeated or very similar and I can onlu guess that
no one exactly knows what each of them and what are the differences
without careful xHarbour core code analyzing. Here the situation
in Harbour is also bad. I left many functions just for backward
compatibility but without any doubts some of them should be removed
and rest replaced by new small set of functions with precisely
defined actions. We should also agree some extensions so they can
be implemented in all places. If we do not understand something
in current implementation then we should remove it - I'm serious
there are things which never worked or stop to work correctly long
time ago and now it's not possible to guess why we have them and
what they should exactly do. In last week I tried to document
xHarbour HVM OOP functions and compare the to Harbour. Also with
other functionality and it's really gray area. I.e. why xHarbour
has PUBLISHED scope. Looks that it's the same as EXPORT + persistent
flag or at least it duplicates such functionality but with separate
set of functions (also duplicated). For serialization code new
duplicated functions were added which tries to merge both functionality.
To make it more complicated we have yet another serialization method
by HBPRESISTENT class which is merged with other serializations with
many side effects, etc.

>> The windows only extensions and windows API wrappers have WIN_ and
>> WAPI_ prefixes in Harbour and are part of HBWIN library. I think it's
>> good solution because it well separates non portable MS-Windows only
>> code what helps users to create portable programs and isolate local
>> to system extensions.
> Agree, except, I would in general prefer resolution by means of
> namespace support. IMO, NameSpaces are critical feature of any
> modern compiler, and long ago we should have implemented and
> standardized namespace usage to have code like this:
> USING NAMESPACE Clipper
> To force usage of STRICT Clipper compatible RTL Functions, vs.
> USING NAMESPACE Harbour
> To prefer EXTENDED Clipper RTL. or of course manual overrriding:
> Clipper.SubStr(...) vs. Harbour.SubStr(), etc.
> As well as:
> USING NAMESPACE Windows
> I hope you agree that it is more flexible, and elegant, then using prefixes.

I agree that namespace is very important. Anyhow it is much more wider
problem which has many interactions with compiler and with HVM at runtime
when dynamic libraries are loaded and unloaded during application life.
In case of [x]Harbour it also interacts with macrocompiler so we need
dynamic code execution context. Such context should resolve also other
things like limited functionality (sandboxes) for foreign code. Finally
it should also include support for named parameters with default
values what seems to be very important in current days, i.e. I have
dynamic JSON RPC (1.0 and 2.0) server, client and peer connection library
for Harbour so I can exchange data with most of other languages but without
named parameters in core Harbour code it has reduce functionality to
position parameters or dedicated user functions which can decode default
parameter values from partial parameters in hash array.
A lot of things have to be changed to fully implement everything and
I'm not sure it can be done in reasonable time by volunteers.

>> The namespace support is sth what you will have to make yourselves.
>> I'm not familiar with this code.
> It has been many years since I wrote it, and I know it is not 100%
> elegant, due to reliance on PP code, and having to use multiple
> compilation when cyclic reliance between 2 sources exists, but I
> believe it to be very complete and stable, and it offers great
> flexibility and full namespace support, to both C code, and PRG
> code, as well as Macro executed code. I would strongly appreciate
> your review \xharbour\doc\namespaces.txt for the full set of
> functionality it offers, in terms of a Namespace MODEL, then we
> could discuss the code, which I am really much less interested in.

OK, I'll try to look at it in spare time.

>> In Harbour compiler can be used at runtime. It means that
>> program which works like xBaseScript can be implemented in just few
>> lines and .prg files are executed with full speed just like
>> after -gc2 compilation.
> Interesting - what about the copyright exception which was NOT given
> to the Compiler sources?

Still exists so such programs have to be released on GPL license.
In fact in Harbour the folowing files do not contain Harobur excption:
cmdcheck.c
genc.c
genhrb.c
harbour.y
hbfunchk.c
hbgenerr.c
hbident.c
hbmain.c
A lof of code inside is written by me but not all so I still have on
my TODO list to rewrite them. It can be done quite easy starting
from macrocompiler grammar rules and creating new flow control for
compiler mode. It should resolve many bad things which are forced
by current grammar rules defined in harbour.y
Anyhow it's not critical for me and I do not find anything wrong
that HBRUN in Harbour is on GPL license.

>> I even create hbscript which can be used as active script in
>> MS-Windows. I haven't committed it yet. It covers similar functionality
> >from xHarbour.com - I tested it with xHarbour examples and they
>> worked well.
>
> Very good

I'll try to commit it soon so you can see it in action.
It was written by me and Mindaugas.
It's pure C code though it defines C++ objects for COM/OLE
interface. If you agree then I would like to attach one of
your html example file from xBaseScript just for comparison.
I'm not MS-Windows programmer so this code to be alive needs
support from Windows users.

>> The real problem can appear at runtime and is caused by binary
>> compatibility with older code.
>> HB_SERIALIZE() gives incompatible results. It means that
>> HB_DESERIALIZE() from Harbour cannot decode data encoded by
>> current xHarbour HB_SERIALIZE().
>> HB_SERIALIZE() is used by SQLRD so this problem is not such trivial
>> because it may block migrating to new xHarbour version.
>> Probably this can be resolved adding support for signatures used
>> by xHarbour in serialization code. I haven't though about it
>> before. I'll look at it closer and if it's possible I'll commit
>> such patch to Harbour.
> Saw you already committed.

Yes and I added also support for decoding data with cross refrences,
objects and HBPERSITENT objects. I also recognizes correctly serialized
codeblocks skipping their body (decoded as NIL).
It means that now everything except codeblocks serialized directly
or indirectly by xHarbour version of HB_SERIALIZE() is correctly
decoded by Harbour. When I was checking xHarbour serializtion code
I've found some problems which definitely have to be fixed.
I'll commit critical fixes soon.

>> hb_valToExp() gives different results then ValToPrg() but in fact
>> Harbour creates real expressions which can be macrocompiled so it's
>> rather like a fix for current xHarbour behavior.
> Mmm, are you not aware of xHarbour's ValToPrgExp()?

I have to missed it or I exploited some problems with it in the past.
When I touched HB_SERIALIZE() I also checked other serialization code
with some OOP functionality in Harbour and xHarbour. As result I
created new general functions __obj{Set,Get,Restore}IVars() which
can be used as general serialization function regardless of object
definition. They can serialize whole object instance area also
overloaded by descendant classes which needs super casting or
have nonvirtual hidden messages. These functions can be used to
replace all other __obj*() and __cls*() functions which tries to
operate on object instance variables. I also updated hb_valToExp()
to use them so now the serialization is more similar to xHarbour
though it does not use PRIVATE variables so deserialization is
reentrant safe.
In the future I will want to document how programmer can control
which object items should be serialized automatically.
I plan to add support for VAR ... NOSAVE like in xBase++ to
explicitly disable serialization for given variables. For
backward compatibility if objects has variables with PERSISTENT
attribute then only this variables will be saved. It should cover
HBPERSITENT class functionality. Pointer items and codeblock
will be eliminated. Exported persitent variables will give
functional replacement for published scope.

Looking at different serialization code implemented in xHarbour
I tried to document some most important things I found. It should
help in creating one centralized and well documented serialization
code:

1. HB_SERIALIZE()
- it does not serialize timestamp values "T"
- it wrongly serialize LONGLONG values and then cannot desrialize
data containing LONGLONG values
- it does not serialize pointer items "P"
- for objects it uses:
HBPersistent:SaveToText()
or
__ClsGetPropertiesAndValues( oObj )
- stores CODEBLOCKs as "B" + HB_SERIALIZE( HB_SaveBlock( <bCode> ) )

2. ValToPrg() / ValToPrgExp()
- it does not correctly serialize timestamp values "T"
- potential problems with strings containig chr(0) or "\" characters
StringToLiteral() does not work correctly.
- it does not serialize memo strings "M"
- it converts pointer items to numbers "P"->"N"
- no support for cross and cyclic references in hashes
- deserialization by macrocompiler is not reentrant safe so if
execution of macrocompiled data activates some code which may
internally use deserialization of other ValToPrg() values then
it breaks upper level data because it operates on common private
variable. It is not unusual situation, i.e. it cannot be used
with code where objects retrieve their initial state from
serialized data inside constructors.
- for objects it uses:
__objGetValueDiff( oObj )
effectively it works like __ClsGetPropertiesAndValues( oObj ) in
HBPersistent():SaveToText() but saves also EXPORTED variables and
does not saves private and hidden vars declared with PERSISTENT
attribute.
Unfortunately it wrongly saves CLASSVARs with some unexpected
values extracted from object instance area - this is serious
bug because it badly interacts with deserialization code.

3. HBPersistent():SaveToText()
- it does not correctly serialize hashes (generates broken output)
because it wrongly uses ValToPrg() instead of ValToPrgExp() for
types which are not directly supported.
- no support for cross and cyclic references
- to serialize objects which are HBPersistent class descendant
(so also Self) it uses:
__ClsGetPropertiesAndValues( oObj )
but reduces the properties list to the ones which have different
values different then in object created by:
__ClsInst( Self:ClassH )
- other objects in instance variables are not serialized.

4. Functions to clone complex items at runtime.
They are not strictly serialization functions but share some similar
problems like cross references and creating next object instances so
they have to be synced with serialization code. Now xHarbour has:
AClone(), HClone(), __objClone()
- HClone() in xHarbour does not clone anything, it's simple HCOPY()
so it has to be fixed and bound with AClone() code so they cab use
common references list.
- AClone() - clones only arrays but doesn't clone hashes and does not
make any deeper check for hash contents so items like:
a := { { "V" => NIL } }
a[1,"V"] := a
are not correctly cloned. It means that both functions have to use
common internal clone engine like in Harbour. So far in xHarbour
only HB_SERIALIZE() tries to follow internal references in arrays,
object and hashes.
- __objClone() - it does not clone nested objects - only instance
area is cloned. In xHarbour there is support for class method
declared with CONSTRUCTOR attribute. Such methods are executed with
HB_OO_MCLSCTOR_INSTANCE parameter when new object is created and
with HB_OO_MCLSCTOR_CLONE parameter inside __objClone() function.
It means that theoretically it's possible to implement some custom
initialization for cloned objects and deeper cloning for object
items. Unfortunately it's not bound with internal list of cross
references so user cannot implement custom deep cloning for objects
with internal cross references. Also AClone() is not bound with
it and ignores object with defined clone/copy/init constructor.
This have to be resolved yet also in Harbour. We should agree
how to define copy/init constructors or which messages send to
new objects when they are cloned or deserialized - now
deserialization code completely ignores copy constructors, in
opposite Xbase++ sends :notifyLoaded() message to deserialized
objects so programmer can overload it and make some necessary
initialization.
We should also add support for nested cloning so user can access
cloned item list and redirect it to common clone engine or at
least define that objects support deep cloning so we can use
standard array cloning method for such objects.

I also checked some helper functions used in serialization/clone
operations and here are some notes:
- HB_SaveBlock( <bCode> ) does not serialize detached locals so it's not
necessary to detect cyclic references between them and other data.
Anyhow general codeblock serialization may support it and in such
case it's necessary to bind it with common list of references.
- StringToLiteral() does not work correctly, use HB_STRTOEXP() instead
which gives correct results also for binary strings and it's much
faster.
BTW I'm the author of this function not David
- __objGetValueDiff( oObj )
It uses __clsGetIVarNamesAndValues( Self, HB_OO_CLSTP_EXPORTED + ;
HB_OO_CLSTP_PUBLISHED )
but reduces the properties list to the ones different then in
__clsGetIVarNamesAndValues( __ClsInst( Self:ClassH ), ;
HB_OO_CLSTP_EXPORTED + ;
HB_OO_CLSTP_PUBLISHED )
This reduction (just like in HBPersistent():SaveToText()) does not
work correctly for complex items because they are cloned during
object initialization and deep comparison is not implemented so
it never reduce arrays used in INIT clause in class definition.
- __ClsGetPropertiesAndValues( oObj )
It looks for HB_OO_CLSTP_PUBLISHED or PERSITENT messages which
have non zero uiData index.
It means that it gives wrong results for
CLASS VAR
declared as PUBLISHED and
METHOD/ACCESS/ASSIGN ... INLINE
declared as PERSISTENT or PROPERTY
because they use uiData internally as index to diffeent structures,
this is serious bug.
- __clsGetIVarNamesAndValues( oObj, nScope )
It looks for variables with given scope (or all if scope is 0)
checking message function hb___msgGet*Data().
It gives wrong results for
CLASS VAR
this is serious bug,
fortunately ignores shared vars due to 0 in uiData PMETHOD member.

I also found that either Harbour and xHarbour cannot serialize correctly
supercast objects. In fact the results are unpredictable because it
creates two objects of given class but the first one has only one
element instance are and in this element it has real object. Definitely
it has to be fixed in both compilers. I already added it to my TOFIX list.

Enough, lot about serialization code but binary compatibility with
existing data stored somewhere is usually the most important thing
which can block future development and extensions. This is the
reason why I never liked to add extensions to RDD if they are not
precisely defined and can create anomalies (i.e. SIx3 encryption in
memos). RDDs is yet another thing anyhow here the differences are
much smaller.

In general RDD is subject for separate discussion but here situation
is much simpler. xHarbour has few copies of DBFCDX called BMDBFCDX,
DBFMDX, REDBFCDX, REDBFFPT, DBFNET, etc. All such RDDs can be safely
removed because they do not give any new functionality in comparison
to pure DBFCDX in Harbour core code and BM* RDDs in contrib. There
are some differences in DBF headers but as I can see most of them
you have to remove when people begins to report serious compatibility
problems with Clipper and other xbase compatible languages.

>> I believe that you can quite fast catch all such differences and
>> agree what to do with them.
> Yes, tough I suspect there are many more hidden, such as extension
> to Clipper RTL functions, that in Harbour were either not
> implemented, or implemented as new HB_<SomeFunc>().

Yes but most of them are documented in XHB library so it should
be easy to update the code.

Enough. Now I really have to return to my own work.

best regards,
Przemek

[alaminojunior]

Não pergunto nunca mais, desisto !
Ou quem sabe surge alguém melhor preparado e intencionado para responder.

Foi uma pergunta direta e pratica, esperando quem sabe uma resposta direta e pratica, e o que recebo é novamente uma verborréia alienígena que não me leva a conclusão nenhuma.
Se não tem argumentos diretos e práticos para discutir, por favor não fique denegrindo a imagem desta ferramenta.

Novamente repito: Para o que eu (e muitos colegas) se propõem a fazer, o xHarbour funciona muitíssimo bem. Quem quiser utilizar o Harbour, que use, sem problemas.
Mas ficar denegrindo (sem argumentação) a imagem de uma ferramenta que é o ganha pão de alguns profissionais como eu, é no mínimo infantil.

Desculpe o desabafo, mas tem gente aqui querendo ter um filho do russo.

[Itamar M. Lins Jr.]

Melhor o Sr. me respeitar.
Não lhe devo satisfação nenhuma.
Sua ignorância não deixa ver o óbvio que está escrito muitas coisas nos textos, como falei não é para qualquer um...
Vai estudar mais e pare de indicar porcaria aos outros.
Totalmente no sense vem aqui ofender os outros pula no tópico do letodb para falar mal nem sabe usar o letodb, que dirá entender essas coisas que postei, ainda em inglês, desculpe se te aborreci.
Bem sei quais são as armas da arrogância e da prepotência.

Saudações,
Itamar M. Lins Jr.

[alaminojunior]

Bem sei quais são as armas da arrogância e da prepotência.Itamar M. Lins Jr.

É evidente que sabe !