Miguel: ADS's .ADT files have had extended types forever.
Recently they added VFP support, which now has many similar features for VFP dbf files as well. You added support for VFP here, and the Harbour folks either borrowed or did their own changes there. Do you think part of the problem is that there is confusion between ADT extended field types and VFP extended field types? I'm not yet completely familiar with the VFP changes, but there was an attempt to create similar interfaces/FieldType flags for both, right? Thanks, -- Brian Hays > -----Original Message----- > From: Miguel Angel Marchuet [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 12:49 AM > To: bhays > Cc: 'xHarbour-Developers' > Subject: Re: [xHarbour-developers] RDD compatibility > > > > > > 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 > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 269.24.0/1460 - Release Date: > 5/22/2008 7:06 AM ------------------------------------------------------------------------- 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
