>
> xhb hb
>
> HB_FT_DATETIME HB_FT_TIME
>
> HB_FT_TIMESTAMP HB_FT_DAYTIME
>
> HB_FT_PICTURE HB_FT_IMAGE
>
> (xhb has HB_FT_TIME as no. 21)
>
> I had to change HB_FT_TIMESTAMP and HB_FT_PICTURE in ads1.c so I could
> build
>
I explain some times that some types was introduced by error at DBF format in
harbour.
I'm talking about of specific ADT field types added at DBF.
HB_FT_TIME is too supported at xharbour, but is not the same that HB_FT_DATETIME
HB_FT_DATETIME is T 8 and ( This type is only compatible with DBF of recent VFP
formats )
HB_FT_TIME is T 4 ( but this type are not compatible with any DBF
format )
TIME only saves TIME and is only compatible with ADT
DATETIME is and DBF standard type that saves date and time in 8 bytes.
HB_FT_TIMESTAMP is @ 8 ( This type is only compatible with DBF of recent VFP
formats )
HB_FT_PICTURE is @ 8 ( This type is only compatible with DBF of recent VFP
formats )
HB_FT_PICTURE is @ 8 ( This type is only compatible with DBF of recent VFP
formats )
#define HB_FT_NONE 0
#define HB_FT_STRING 1 /* "C" */ ( Basic type )
#define HB_FT_LOGICAL 2 /* "L" */ ( Basic type )
#define HB_FT_DATE 3 /* "D" */ ( Basic type )
#define HB_FT_LONG 4 /* "N" */
#define HB_FT_FLOAT 5 /* "F" */
#define HB_FT_INTEGER 6 /* "I" */
#define HB_FT_DOUBLE 7 /* "B" */
#define HB_FT_DATETIME 8 /* "T" len 8 */ ( This type is only
compatible with DBF of recent VFP formats )
#define HB_FT_TIMESTAMP 9 /* "@" */ ( This type is only
compatible with DBF of recent VFP formats )
#define HB_FT_MODTIME 10 /* "=" */ ( This type is only
compatible with ADT, please don't use it at DBF )
#define HB_FT_ROWVER 11 /* "^" */ ( This type is only
compatible with ADT, please don't use it at DBF )
#define HB_FT_AUTOINC 12 /* "+" */ ( This type is only
compatible with ADT, please don't use it at DBF )
#define HB_FT_CURRENCY 13 /* "Y" */
#define HB_FT_CURDOUBLE 14 /* "Z" */
#define HB_FT_VARLENGTH 15 /* "Q" */ ( This type is only
compatible with DBF of recent VFP formats )
#define HB_FT_MEMO 16 /* "M" */ ( Basic type )
#define HB_FT_ANY 17 /* "V" */ ( Please don't use it at
DBF it
breaks DBF
compatibility )
#define HB_FT_PICTURE 18 /* "P" */ ( This type is only
compatible with DBF of recent VFP formats )
#define HB_FT_BLOB 19 /* "W" */
#define HB_FT_OLE 20 /* "G" */ ( This type is only
compatible with DBF of recent VFP formats )
#define HB_FT_TIME 21 /* "T" len 4 */ ( This type is only
compatible with ADT, please don't use it at DBF )
Explaining something more, I've to say that ADT don't use a single letter to
define field type, for example
ADT uses:
CHARACTER instead of C
IMAGE instead of P
TIME instead of T-4
TIMESTAMP instead of @
AUTOINC instead of + or flag HB_FF_AUTOINC
BINARY instead of V or flag HB_FF_BINARY
CURDOUBLE instead of Z
DOUBLE instead of B
INTEGER instead of I I'm not sure of this
SHORTINT instead of N I'm not sure of this
DATE instead of D
RAW instead of ^
> Question 1: Are we planning on syncing these changes?
>
> If so, I’ll wait to pull in rddads until that happens since
>
> hacking it locally will just create problems later.
>
> If not, I need to know which hacks are safest.
>
At this moment I don't have time to merge code, but in some days
I will help to port needed changes.
>
> Question 2: in the func table, in ads1.c I had to change
>
> 2 instances of DBENTRYP_RVV with DBENTRYP_RVVL for adsDrop and adsExists.
>
> I’m not sure what the “L” ends up doing here, especially since both
>
> projects have the same code and arg list for these funcs.
This change is needed to be useful, harbour needs to change too it in the future
L means that the 4 parameter of the function is a LONG.
How you can drop a table from SQL server if you don't inform connection as 4
parameter ?
> Is that change appropriate, or are we going to sync usage of these flags
> in that table?
>
You can do it respecting actual define that in my opinion are more correct that
the used
at harbour, almost are the same that are used by others, for example normally
is used TIMESTAMP
instead of DAYTIME to STAMP a date and time when the register is added.
harbour added this field type later and don't respect the use of this type at
great part of RDD
there are single one that uses this nomenclature (ADT)
ALL can be synced but respecting actual define nomenclature and meaning.
Best regards,
Miguel Angel Marchuet
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
