Adam


Returning from the evening dog walk I thought I'll compare the data.

procedure TForm1.Button3Click(Sender: TObject);
var
fc, rc, cc: integer;
begin
TicketQAQ.Open;
TicketQAQ2.Open;
TicketQAQ.First;
TicketQAQ2.First;
fc := TicketQAQ2.FieldCount;
rc := 1;
while not TicketQAQ.Eof do begin
 for cc := 0 to fc - 1 do begin
  if TicketQAQ.Fields[cc].AsString <> TicketQAQ2.Fields[cc].AsString then begin
//    Memo1.Lines.add('Row: ' + IntToStr(rc) + ' Column: ' + IntToSTr(cc)+'   '+TicketQAQ2.Fields[cc].DisplayName+ '  '+IntToStr(integer( TicketQAQ2.Fields[cc].datatype)));
Memo1.Lines.add('Row: ' + IntToStr(rc) +'x'+ IntToSTr(cc)+  ' ['+ TicketQAQ.Fields[cc].AsString +']   ['+ TicketQAQ2.Fields[cc].AsString+']');
  end;
 end;
 TicketQAQ.Next;
 TicketQAQ2.Next;
 in


Its different. So unless I've screwed up somewhere with my little test you're  comparing apples and elephants.


Roy Lambert

Hi Roy,

Thanks for that. I've taken a look, and for the most part it appears to
be the order of the result set in the queries, as well as the order of
the fields.

I have modified the application so both queries have the same field
orders, as well as the same order by. (Ordering by ticket alone was
bringing different results), but the problem still remains.

However, in doing so - I've gone one step further, and have found part
of the problem.

The Contract field (in the BDE) contains zero values, whereas DBISAM
contains NULL values.

If I remove the contract field from the TxQuery SQL, DBISAM behaves the
same as the BDE.

I'll keep investigating futher. Thanks very much for your help. (What
I'm hoping to do is to get the BDE to break the same as DBISAM - and
then I can supply a demo example of the issue to the developers).

Best Regards

Adam.

Hi Roy,

Partial Success! (Thanks to you putting me on the right track.)

In looking at the differences between the two datasets, I've been able
to replicate the problem using the BDE via:

update xquery set contract = null where contract = 0

Now when I re-run the query using the BDE, I have the same problem.

While not a solution in itself, it does confirm my suspicions that the
problem is not with DBISAM, and also gives me a project I can submit for
debugging.

Many thanks for getting me off my tunnel focus!

Cheers

Adam.

Adam


Roy's golden rules for debugging:

1. suspect the data
2. suspect Roy
3. think about everything else

I think I had a major advantage over you - I had no idea what TxQuery was doing so I simply black boxed it, stuffed in a wadge of tracing and went from there. I noticed that there were calls to some sort of null test and given my aversion to nulls did wonder about that especially since two databases were involved.

Good luck with sorting it out.

Roy Lambert

Hi Roy,

> Roy's golden rules for debugging:
>
> 1. suspect the data
> 2. suspect Roy
> 3. think about everything else

LOL - love step no 2.


> I think I had a major advantage over you - I had no idea what TxQuery was doing so I simply black boxed it, stuffed in a wadge of tracing and went from there. I noticed that there were calls to some sort of null test and given my aversion to nulls did wonder about that especially since two databases were involved.

I actually like Nulls personally. (Well, when Nulls can be considered
the same as empty values that is  )

But in this instance it definitely looks like TxQuery is struggling with
them. Still not sure why - but at least I have a working demo with the
BDE that others who know a lot more than me about this component can
duplicate.

I also think you were right about the problem being elsewhere, not in
the comparemem section - so once again, thanks!

In the mean time, I've been able to work around the problem by doing a
coalesce, and applying a '0' value to the field in question if it is
null prior to loading into TxQuery.

I just kinda wish I could get my head around pointers and memory
management a little more. (Strewth, I used to think that threads were a
mind trip!  

Cheers

Adam