[Harbour] RE: [xHarbour-developers] Extended field types in RDDs

[bhays]

Przemek:
Regarding ADTs and Numeric types:

>>> ...using "N" in old code instead of one of the more specific types.
PC>I remember about it. I think that we should change our ADT RDD code to
work in the same way with different ADS versions. Now depending on ADS
server version different tables are created and IMHO it's wrong and can be
source of problems.

I'm happy to do a change, but I couldn't come up with a viable logic for it.
Unless we just go to a compiler switch or global setting which dictates
"old way or new way", which didn't sound good either.

My first thought -- to interpret just "N" as the old way (because that's
what
most old code *probably* used) and require "Numeric" for the new
true Numeric type -- isn't good enough.
If we accept this statement:
	For someone starting new and using ads 8.1,
	"N" should go straight to the Numeric type.
which makes sense to me, then "old code" will indeed have
to have the new behavior too unless there's some other
indicator to be v8.0 and earlier compatible.
So we're back to yet another switch.
BTW, the existing ads version directive isn't viable for
controlling this behavior for a lot of reasons.

--
  Brian Hays


> > For low level representation ADS RDDs use uiTypeExtended member of
> DBFIELDINFO structure putting inside ADS_* integer number which
> describes field type (this was the source of potential conflicts
> between ADS and VIC DBF autoinc implementation) I can help do whatever
> workarounds we may need to support old code plus the new system.  I
> think an RDD all-inclusive compatible top layer of all field types (to
> get mapped to each specific rdd field as needed) is important.
>
> >    "MEMVAR_COMPRESSED_ENCRYPTED_BINARY"
> > so IMHO it's not real solution.
> I agree.
>
> > In new FlagShip versions the first letter of field type is table field
> > type and next ones are flags, f.e. for above we will have:   "MCEB" This
> > seems to be much better solution for me and probably is less
> > intrusive for existing code.
> OK.
>
> > We can also make sth between FlagShip and CLIP. We can extend
> > structure array but add only one 5-th character column with flags
> > described like in FlagShip. Alternatively it can be numeric column
> > with bit field for different flags.
> > This also seems to be reasonable solution.
>
> This sounds better to me.
> MEMVAR+COMPRESSED+ENCRYPTED+BINARY

With 5-th column we can implement both: character and numeric attributes -
dbcreate() will translate them to numeric values so RDD code will not have
to know about it.

> > If you have any other propositions then I'd like to hear about them.
> One way or another, it seems we need a list of flags.  Are they always
> just logical flags or are there any properties that require some
> value?  If it really is just flags, the bit fields seems appropriate.
> We could have constants for the most common combinations, and people
> could do the addition/bitAnd operations for more complex types.

So far I'm talking about logical attributes.
There are also some other things like default field value, range
description, validate functions, trigger functions, etc.

> >   (2) What structure should we chose for dbCreate()/dbStruct() array?
> I'm not sure if I missed something. It seems to me to have become just
> an added 5th column storing a number/bitfield?
>
> > Finally I'd like to talk about low level representation for field
> > structure. Now we are using this structure:
> > We have two problems.
> > 1. Where we should keep field flags?
> Types should be only the largest, most "integral" types -- not
combinations.
> As we found with "Numeric", any string starting with "N" pretty much
> works in clipper, so going beyond one char is problematic.
> And of course with just one char we're running out of values soon.

OK.

> >.... To avoid such strange "extensions" which
> >   sooner or later will be in conflict with HVM I'd like to replace
> >   HB_IT_* values in uiType by HB_FT_* ones which will be only for
> >   RDD use.
> Sounds good to me.
>
> > In summary I'd like two sets with HB_FT_* (Field Type) and HB_FF_*
> > (Field
> > Flag) definitions. Store HB_FT_* in uiType and find a place for
> > HB_FF_*. We can use uiTypeExtended as holder or we can add new
> > member to DBFIELDINFO,
> > f.e.: USHORT uiFlags. Personally I vote for new field for two reasons:
> Sounds good to me.  As for the list of types, should we consider the
> special needs of "Currency" ?

There are two methods of representing currency: as double and as i64.
"Y" in DBF means currency as it's i64 value. In ADS it's "Money"
I do not know what is the difference between CurDouble and Double fields in
ADS and why they have two separated types for them.

> Here's the current list of ADT field types. Newer special ones are
> CICharacter (case insensitive), CurDouble,

Does ADS make any conversions (upper/lower) on values assinged to
CICharacter fields?
Is this attribute used in index expression or automatic conversion
(upper/lower) causes that is not necessary to respect it?

things like IGNORE CASE, UPPER, LOWER can be field attributes.

> ModTime - automatically updated with current date/time when a record
> is updated; and Rowversion - automatically incremented when a record
> is updated for purpose of "isChanged" flag.

Nice features - I like them so in some spare time I'll add them to DBF*
RDDs.

> Character
> CICharacter
> Date
> Logical
> Memo
> Double
> Integer
> Numeric
> Image
> Binary
> ShortInteger
> Time
> TimeStamp
> AutoIncrement
> Raw
> CurDouble
> Money
> ModTime
> RowVersion
>
> I attached a little spreadsheet from their HLP file in case it helps
> to check their details.

Thank you.

best regards,
Przemek