URGENT - ADS not reading DBFCDX files correctly
in [Visual Objects]
|
Prev: OwnerDraw ListView
Next: SO Service Client V1.4.0
From: Marc Verkade [Marti] on 25 May 2010 12:45 Hey, This is what we have at the start of the program: // Init CaVo Settings SetDateCountry(FRENCH) SetDeleted(TRUE) RDDINFO(_SET_MEMOBLOCKSIZE,64) DbSetRestoreWorkarea( TRUE ) SetEpoch(Year(Today())-80) SetAnsi(FALSE) // Sorting in XP and Vista the same way in Dutch SetAppLocaleID(MAKELCID(1043, SORT_STRINGSORT)) // Set the other ADS stuff IF SELF:IsADS AX_AXSLocking( TRUE ) // use proprietary // SET OPTIMIZE ON RDDINFO(_SET_OPTIMIZE,TRUE) END"Dave Francis" <suilvenassociates(a)googlemail.com> schreef in bericht news:21b32825-8415-4f98-b7ec-8c20821c5deb(a)o1g2000vbe.googlegroups.com... > Nick, > > MS made ansi sequence changes between XP and Vista (perhaps to W7 > too). Could that be a factor? Or, perhaps, the language settings on > the respective machines? > > HTH > > Dave Francis > > Thre were > On 25 May, 08:56, Nick Friend <nicktek...(a)googlemail.com> wrote: >> As usual it's part of a very large app and very difficult to extract. >> >> Digging deeper I'm seeing the following.... >> >> 1. We have existing DBFs being used with our VO DBFCDX app. These are >> ANSI but with memoblock size 32. >> 2. In the process of upgrading to the ADS version, the program takes >> the files and rebuilds them with memoblock size 64, simply using >> DBServer:CopyDB, just using the normal DBFCDX driver. At this point >> there seems to be a character issue as for example superscript 2 is >> getting changed to an umlauted character. Can't find what setting is >> causing this despite heaps of experiments. >> >> This is a pain, but I don't think it's the source of our main problem, >> as I did a manual edit of the files to change the memoblock size, >> preserving the special characters correctly, and the main problem of >> data inconsistency continued. >> >> 3. Once the data is in the ADS compatible form and running under ADS, >> we see the following in one particular situation (which was the cause >> of the original post). One section of code in particular is using a >> DbServer:SetRelation to a child table. The lookups on the child table >> are failing, apparently in a regular fashion. >> >> The logic of this bit of code is quite complex, so I'm going to try >> and document what's going on, to see if anyone can shed some light. >> >> Nick >
From: Dave Francis on 25 May 2010 14:41 Mark, But would SetAppLocaleID(MAKELCID(1043, SORT_STRINGSORT)) have any effect at the server? I'm wondering if there is a inconsistency with the 2 boxes hosting the ADS servers. That's where the ADS indexing algorithm would be evaluated, wouldn't it? Presumably some of the data was loaded onto both servers at the start of the project. If the records that don't match after replication starts, are ALL newer or amended records (or ALL original ones), then the servers must be using a different standard to write the data or indexes? What do you specify in the server ADS.INI? IIRC ADS defaults to the locale of the server. Dave Francis On 25 May, 17:45, "Marc Verkade [Marti]" <marc...(a)rti.nl> wrote: > Hey, > > This is what we have at the start of the program: > > // Init CaVo Settings > SetDateCountry(FRENCH) > SetDeleted(TRUE) > RDDINFO(_SET_MEMOBLOCKSIZE,64) > DbSetRestoreWorkarea( TRUE ) > SetEpoch(Year(Today())-80) > SetAnsi(FALSE) > > // Sorting in XP and Vista the same way in Dutch > SetAppLocaleID(MAKELCID(1043, SORT_STRINGSORT)) > > // Set the other ADS stuff > IF SELF:IsADS > AX_AXSLocking( TRUE ) // use proprietary > // SET OPTIMIZE ON > RDDINFO(_SET_OPTIMIZE,TRUE) > END"Dave Francis" <suilvenassocia...(a)googlemail.com> schreef in berichtnews:21b32825-8415-4f98-b7ec-8c20821c5deb(a)o1g2000vbe.googlegroups.com... > > > Nick, > > > MS made ansi sequence changes between XP and Vista (perhaps to W7 > > too). Could that be a factor? Or, perhaps, the language settings on > > the respective machines? > > > HTH > > > Dave Francis > > > Thre were > > On 25 May, 08:56, Nick Friend <nicktek...(a)googlemail.com> wrote: > >> As usual it's part of a very large app and very difficult to extract. > > >> Digging deeper I'm seeing the following.... > > >> 1. We have existing DBFs being used with our VO DBFCDX app. These are > >> ANSI but with memoblock size 32. > >> 2. In the process of upgrading to the ADS version, the program takes > >> the files and rebuilds them with memoblock size 64, simply using > >> DBServer:CopyDB, just using the normal DBFCDX driver. At this point > >> there seems to be a character issue as for example superscript 2 is > >> getting changed to an umlauted character. Can't find what setting is > >> causing this despite heaps of experiments. > > >> This is a pain, but I don't think it's the source of our main problem, > >> as I did a manual edit of the files to change the memoblock size, > >> preserving the special characters correctly, and the main problem of > >> data inconsistency continued. > > >> 3. Once the data is in the ADS compatible form and running under ADS, > >> we see the following in one particular situation (which was the cause > >> of the original post). One section of code in particular is using a > >> DbServer:SetRelation to a child table. The lookups on the child table > >> are failing, apparently in a regular fashion. > > >> The logic of this bit of code is quite complex, so I'm going to try > >> and document what's going on, to see if anyone can shed some light. > > >> Nick > >
From: Marc Verkade [Marti] on 25 May 2010 14:41 ADS.INI is standard, no fancy stuff. The SetAppLocaleID is a thing I grabbed from the NG "Dave Francis" <suilvenassociates(a)googlemail.com> schreef in bericht news:5e6faa28-e04f-4953-a86d-5f5595b24bdb(a)q33g2000vbt.googlegroups.com... > Mark, > > But would > > SetAppLocaleID(MAKELCID(1043, SORT_STRINGSORT)) > > have any effect at the server? > > I'm wondering if there is a inconsistency with the 2 boxes hosting the > ADS servers. That's where the ADS indexing algorithm would be > evaluated, wouldn't it? Presumably some of the data was loaded onto > both servers at the start of the project. If the records that don't > match after replication starts, are ALL newer or amended records (or > ALL original ones), then the servers must be using a different > standard to write the data or indexes? > > What do you specify in the server ADS.INI? IIRC ADS defaults to the > locale of the server. > > Dave Francis > > On 25 May, 17:45, "Marc Verkade [Marti]" <marc...(a)rti.nl> wrote: >> Hey, >> >> This is what we have at the start of the program: >> >> // Init CaVo Settings >> SetDateCountry(FRENCH) >> SetDeleted(TRUE) >> RDDINFO(_SET_MEMOBLOCKSIZE,64) >> DbSetRestoreWorkarea( TRUE ) >> SetEpoch(Year(Today())-80) >> SetAnsi(FALSE) >> >> // Sorting in XP and Vista the same way in Dutch >> SetAppLocaleID(MAKELCID(1043, SORT_STRINGSORT)) >> >> // Set the other ADS stuff >> IF SELF:IsADS >> AX_AXSLocking( TRUE ) // use proprietary >> // SET OPTIMIZE ON >> RDDINFO(_SET_OPTIMIZE,TRUE) >> END"Dave Francis" <suilvenassocia...(a)googlemail.com> schreef in >> berichtnews:21b32825-8415-4f98-b7ec-8c20821c5deb(a)o1g2000vbe.googlegroups.com... >> >> > Nick, >> >> > MS made ansi sequence changes between XP and Vista (perhaps to W7 >> > too). Could that be a factor? Or, perhaps, the language settings on >> > the respective machines? >> >> > HTH >> >> > Dave Francis >> >> > Thre were >> > On 25 May, 08:56, Nick Friend <nicktek...(a)googlemail.com> wrote: >> >> As usual it's part of a very large app and very difficult to extract. >> >> >> Digging deeper I'm seeing the following.... >> >> >> 1. We have existing DBFs being used with our VO DBFCDX app. These are >> >> ANSI but with memoblock size 32. >> >> 2. In the process of upgrading to the ADS version, the program takes >> >> the files and rebuilds them with memoblock size 64, simply using >> >> DBServer:CopyDB, just using the normal DBFCDX driver. At this point >> >> there seems to be a character issue as for example superscript 2 is >> >> getting changed to an umlauted character. Can't find what setting is >> >> causing this despite heaps of experiments. >> >> >> This is a pain, but I don't think it's the source of our main problem, >> >> as I did a manual edit of the files to change the memoblock size, >> >> preserving the special characters correctly, and the main problem of >> >> data inconsistency continued. >> >> >> 3. Once the data is in the ADS compatible form and running under ADS, >> >> we see the following in one particular situation (which was the cause >> >> of the original post). One section of code in particular is using a >> >> DbServer:SetRelation to a child table. The lookups on the child table >> >> are failing, apparently in a regular fashion. >> >> >> The logic of this bit of code is quite complex, so I'm going to try >> >> and document what's going on, to see if anyone can shed some light. >> >> >> Nick >> >> >
From: IanB on 25 May 2010 15:23 Hi Nick We use the settings below (i.e. NOT Ansi) and have never had any problems when running AXDBFCDX and DBFCDX - we did have to convert the FPT's to 64 Bytes and we use RDDINFO(_SET_MEMOBLOCKSIZE,64) and then re-create the DBF file (using DBCreate and AXDBFCDX) and do a DBApp() into the new file. - Once its been done the files work between AXDBFCDX and DBFCDX (even though we do not now us DBFCDX, just Local version of ADS if we need to) - Sounds like it may just be that you are using ANSI. SetAnsi(FALSE) SetCollation(#CLIPPER) SetExclusive(FALSE) and if using ADS AdsSetDateFormat("DD/MM/YYYY") p.s. nice to meet you at the DevShare last week.
From: Nick Friend on 25 May 2010 17:12
Thanks Ian.... and everyone else who has contributed. It seems I've got it all sorted. There definitely seems to be an issue with SetRelation - this was the last place I was still using it in our code, so now it's been consigned to the dustbin and everything works correctly. The character problems were, as you may have guessed, me being a stupid git with SetAnsi settings. We've also had an issue with connection handles that I've been hassling ADS support with... that has also been sorted and again was more or less my fault :-( Still got a couple of minor issues, but nothing serious (I hope), and replication is working beautifully and virtually instantaneously. Nick PS. Ian, I'm still jealous of your ReportPro ;-) On 25 May, 20:23, I...(a)Ulysses.co.uk wrote: > Hi Nick > > We use the settings below (i.e. NOT Ansi) and have never had any > problems when running AXDBFCDX and DBFCDX - we did have to convert the > FPT's to 64 Bytes and we use RDDINFO(_SET_MEMOBLOCKSIZE,64) and then > re-create the DBF file (using DBCreate and AXDBFCDX) and do a DBApp() > into the new file. - Once its been done the files work between > AXDBFCDX and DBFCDX (even though we do not now us DBFCDX, just Local > version of ADS if we need to) - Sounds like it may just be that you > are using ANSI. > > SetAnsi(FALSE) > SetCollation(#CLIPPER) > SetExclusive(FALSE) > > and if using ADS > AdsSetDateFormat("DD/MM/YYYY") > > p.s. nice to meet you at the DevShare last week. |