Prev: OwnerDraw ListView
Next: SO Service Client V1.4.0
From: Nick Friend on 24 May 2010 18:13
We've been working to get our DBFCDX application working under ADS to
be
able to use replication. Everything appeared to be fine, but now with
our
first live install, we've noticed that we're getting some horrifying
effects.... We hadn't spotted this in testing as it's not apparent at
first
sight.

In brief, files read through the ADS RDDs are not being accessed
correctly.
It's a little difficult to describe, but for example one calculation
routine
goes to a main DBF where details of an activity are stored, then off
to a
detail DBF to search on an index and total some values of individual
components used in the activity. Using ADS we get back wrong values,
with
some of the records in the detail DBF simply missed. If we open the
same
tables with the old version of our app using DBFCDX, everything is
fine.

This is being accessed through a data dictionary in ADS.

I've tried deleting CDXs (the files have auto-create set in the
dictionary),
but it makes no difference.

It definitely seems to be index related, as I've also noticed that if
I edit
one of the detail records (in our client app) in the ADS version, it
quite
often throws up an error that one of the components hasn't been found,
I do
a refresh by moving to the next record, then back, and the "missing"
component reappears.

The index expressions being used are purely numeric.

Anyone got any idea what the hell is going on.

TIA

Nick Friend
From: Marc Verkade [Marti] on 24 May 2010 18:50
Hey,
I have never experienced thge behaviour you are describing here.
Can you reproduce it in a small app?
When you send that to Peter Funk, I know he will be responsive.

Sorry I have no bettrer answer.
Regards, Marc


"Nick Friend" <nicktekhne(a)googlemail.com> schreef in bericht
news:9fdde2b2-5acb-431e-b678-b4dd13819dc4(a)k31g2000vbu.googlegroups.com...
> We've been working to get our DBFCDX application working under ADS to
> be
> able to use replication. Everything appeared to be fine, but now with
> our
> first live install, we've noticed that we're getting some horrifying
> effects.... We hadn't spotted this in testing as it's not apparent at
> first
> sight.
>
> In brief, files read through the ADS RDDs are not being accessed
> correctly.
> It's a little difficult to describe, but for example one calculation
> routine
> goes to a main DBF where details of an activity are stored, then off
> to a
> detail DBF to search on an index and total some values of individual
> components used in the activity. Using ADS we get back wrong values,
> with
> some of the records in the detail DBF simply missed. If we open the
> same
> tables with the old version of our app using DBFCDX, everything is
> fine.
>
> This is being accessed through a data dictionary in ADS.
>
> I've tried deleting CDXs (the files have auto-create set in the
> dictionary),
> but it makes no difference.
>
> It definitely seems to be index related, as I've also noticed that if
> I edit
> one of the detail records (in our client app) in the ADS version, it
> quite
> often throws up an error that one of the components hasn't been found,
> I do
> a refresh by moving to the next record, then back, and the "missing"
> component reappears.
>
> The index expressions being used are purely numeric.
>
> Anyone got any idea what the hell is going on.
>
> TIA
>
> Nick Friend

From: Nick Friend on 25 May 2010 03:56
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 08:31
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: Nick Friend on 25 May 2010 09:33
Thanks Dave. I think I've tried every possible way of using SetAnsi,
SetCollation etc., but the only way to avoid it seems to be to avoid
using the CopyDB method.

It's probably something very simple, but I just don't have the time to
sit and go through it calmly as we have a client going hysterical, so
I've done a quick manual fix to get round the immediate problem.

By the way I've also found that the SetRelation that I referred to
before is definitely causing problems with ADS. I've had to do a bit
of emergency reprogramming to remove it from our code and do direct
seeks instead. Having done that, things work ok. Have you ever had
those sorts of issues?

Nick

On 25 May, 13:31, Dave Francis <suilvenassocia...(a)googlemail.com>
wrote:
> 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
>
 |  Next  |  Last
Pages: 1 2 3
Prev: OwnerDraw ListView
Next: SO Service Client V1.4.0