> My guess for now is that they both just show a different record of that
> table ADDRESS as that is possible.

It turns out that this is not the case, so I am no further with this. I
can't query the data with isql as this
is not my database and the customer is off now for some days.
I have ruled out linebreaks etc. causing this, so I have no idea at all what
could be doing this.
Any ideas/suggestions greatly appreciated.

RBS


_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of RB Smissaert
Sent: 31 December 2009 08:03
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Corrupted data FB 1.5




From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
yahoogroups.com
[mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
yahoogroups.com] On Behalf Of Helen Borrie
Sent: 31 December 2009 00:52
To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
yahoogroups.com
Subject: RE: [firebird-support] Corrupted data FB 1.5

At 09:43 AM 31/12/2009, you wrote:

>Have tested this now in a database and found that a chr(0) in the text
>cannot cause this behaviour as it won't then show the bit
>after the chr(0) in either application. In VB this was tested by doing an
>update of a table field with the string:
>
>"123" & chr(0) & "567"
>
>So, there has to be something else going on or it has to be a different
>character to cause the trouble.

1. Considering that you can "see" the whole string in one application and
not in another, it can't be seen as "corrupted data". It looks like a
difference in the way the respective visual interfaces display the strings.
Could it be that the problem data contains linebreak characters, that one
application treats as trimmed whitespace, while the other applies the actual
linebreak behaviour, meaning it can't display the rest of the string in a
single-line control?

2. Have you queried the "offending" records using isql?

./heLen


Thanks; with corrupted data I meant there is something the matter with the
data that causes problems.
I have tried with "123" & Chr(13) & Chr(10) & "678" and also "123" & Chr(13)
& "567" and "123" & Chr(10) & "567"
but that makes the data not show up in the first application and show up
normal in Excel, so obtained via ODBC and ADO.
My guess for now is that they both just show a different record of that
table ADDRESS as that is possible. If that is
not the case than I am really baffled.

RBS

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]