Hi Przemek,
Many thanks for your answer, I've just noticed your mail
today, sorry.
I'm processing it, trying to make modifications and will
get back to you. I agree with grouping RDD modifications,
1.1 seems like a good opportunity to make some changes.
MT support may require it anyway, if for nothing else the
changed Set() interface.
One part which might be much for me is the memo handling,
I'd appreciate your help in this area.
Brgds,
Viktor
It needs some additional modification:
> 1. it does not touch memo files and memo RDD at all. I has to be fixed.
> 2. <cAlias> is obligatory in dbCreateTemp() so RT error should be generated
> when it's missing though we can add support for empty alias ("") which
> is also legal in Clipper. In such case alias is not allocated at all
> and not generated from file name. So we have to choices when szAlias
> is NULL. Assing "" to it or generate RT error. The RT error should be
> made in dbCreateTemp() function. In the C function
> hb_rddCreateTableTemp()
> we should have:
> if( szAlias == NULL )
> szAlias = "";
I'd vote for RT error.
>
> 3. pInfo.fTemporary is not initialized in hb_rddOpenTable() and
> hb_rddCreateTable() what will cause very serious bugs.
>
> Rest should be OK though I haven't look at it very deeply but I see one
> problem with adding new member to DBOPENINFO.
> In practice it means breaking binary compatibility so any existing 3-rd
> party RDDs will stop to work and will have to be recompiled for new code.
> Such modifications should be made only if they are strictly necessary and
> we should group them with other modifications we plan to introduce to not
> force unnecessary upgrades or create problems when user will try to use
> old binaries with new Harbour code. I do not know how many 3-rd party RDDs
> exist for Harbour. For sure MEDIATOR. If you know some others then please
> send some information here.
xhb RDDs shipped as binaries, but I've never tried them
with Harbour and it's difficult to guess whether they are
working even without these modifications.
> Jacek used to read this list so there is a chance that he will release
> new MEDIATOR version for Harbour quite fast. Anyhow I also want to make
> some other modifications in RDD structures (f.e. reorder some members to
> make them alignment independent) and such modification should be done
> together. Probably it should be the part of type modifications which also
> may interact with this code so I suggest to not introduce this one now.
> It's also possible to not change DBOPENINFO but pass information about
> temporary flag using DBI_* or RDDI_* interface. Such method is already
> used in some places, f.e. in SIX3 to pass encryption password when table
> is open or even in the function you created (hb_rddCreateTableTemp()) to
> set field delimiters by DBI_SETDELIMITER. BTW pDelim is used in practice
> only by DELIM export RDD and I do not know if it's necessary to keep it
> in hb_rddCreateTableTemp(). You can remove it and add code which will
> pass temporary flag as DBI_ISTEMPORARY, f.e.:
> errCode = SELF_INFO( pArea, DBI_ISTEMPORARY, pTrueItm );
> and change in dbf1.c:
> case DBI_ISTEMPORARY:
> hb_itemPutL( pItem, pArea->fTemporary );
> break;
> to:
> case DBI_ISTEMPORARY:
> if( !pArea->pDataFile && pArea->pMemoFile && HB_IS_LOGICAL( pItem )
> )
> pArea->fTemporary = hb_itemGetL( pItem );
> else
> hb_itemPutL( pItem, pArea->fTemporary );
> break;
> and do not change DBOPENINFO structure.
> In such case we can introduce it even now of course after resolving the few
> problem above.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
