Compare text issue

Brian Donahue

Hi Eric,

Thanks for writing. Your problem with SQL Data Compare is not a known
problem, but give me a day of so to run a test against SQL Data Compare and
I'll try to acqaint myself with it a bit better. :-)

Brian Donahue
Red Gate Technical Support

"lakusha@excite.com" <Lakusha@excite.com> wrote in message
news:BD0I%23NuVDHA.1520@server53...
>
> Hello,
>
> I've noticed that Text fields can now be compared (version 3). So there's
no
> more "incomparable columns". But there seem to be problems with text
> comparisons.
>
> a) I update an empty db with the generated script
> b) a second compare is done automatically but many records differ.
>
> I think the difference is the text columns. When I click on a text link in
> the Different Records tab the text displayed are different. There are a
few
> missing in the updated text field. Is this a known problem with SQL
> DataCompare 3.0?
>
> regards,
>
> Eric
>
>

Brian Donahue

Hi Eric,

There seems to be a bug in the new SQL Data Compare, then. If your text
contains backslashes and carriage returns, the backslashes are not
surrounded in quotes as they should be and SQL Server will treat them like
continuation lines. We'll get this fixed as soon as possible.

Thanks for contacting us about this.

Regards,
Brian Donahue
Red Gate Software Support

"lakusha@excite.com" <Lakusha@excite.com> wrote in message
news:l4ISUp4VDHA.1488@server53...
> Hi Brian,
>
> I *think* I've I've identified the source of the problem.
> I've found the following info in the "Embedded SQL for C and SQL Server"
> section of BOL:
>
> --- quote ---
> You can use a backslash () to continue Embedded SQL strings across more
> than one line of source code. A single quotation mark must precede the
first
> character of the Embedded SQL string on the first line of source code, and
a
> single quotation mark must appear after the last character of the string
on
> the last line of source code. For example:
>
> EXEC SQL INSERT INTO TEXT132 VALUES ('TEST 192 IS THE TEST FOR THE R> ULE OF THE CONTINUATION OF LINES FROM ONE LINE TO THE NEXT LINE.');--- end
> quote ---
>
> So the problem happen only when the text have + return in it. You can
> reproduce it with this:
>
> a) Insert into #test(tText) select 'test> aaa'
>
> Select tText from #test
>
> tText
>

---

> testaaa <---- Missing + return
>
> But the following script fixes the problem:
>
> Insert into #test(tText) select 'test>
> aaa'
>
> I don't know if there is another workaround to this. I'm still
> investigating.
>
> Eric
>
>
> "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
> news:UYPYpY4VDHA.1488@server53...
> > Hi Eric,
> >
> > Thanks for writing. Your problem with SQL Data Compare is not a
known
> > problem, but give me a day of so to run a test against SQL Data Compare
> and
> > I'll try to acqaint myself with it a bit better. :-)
> >
> > Brian Donahue
> > Red Gate Technical Support
> >
> > "lakusha@excite.com" <Lakusha@excite.com> wrote in message
> > news:BD0I%23NuVDHA.1520@server53...
> > >
> > > Hello,
> > >
> > > I've noticed that Text fields can now be compared (version 3). So
> there's
> > no
> > > more "incomparable columns". But there seem to be problems with text
> > > comparisons.
> > >
> > > a) I update an empty db with the generated script
> > > b) a second compare is done automatically but many records differ.
> > >
> > > I think the difference is the text columns. When I click on a text
link
> in
> > > the Different Records tab the text displayed are different. There are
a
> > few
> > > missing in the updated text field. Is this a known problem with SQL
> > > DataCompare 3.0?
> > >
> > > regards,
> > >
> > > Eric
> > >
> > >
> >
> >
>
>

Brian Donahue

Hi Eric,

We'd all love a bit more screen real estate, no? :-) I'll forward this
message to the relevant GUI developer and demand an apology.

Regards,
Brian Donahue
Red Gate Support

"lakusha@excite.com" <Lakusha@excite.com> wrote in message
news:J0SzJg3WDHA.1488@server53...
> Thanks Brian.
>
>
> ps: There is another problem with the current version of SQL Compare. When
I
> executed a synch, there were much warnings returned by sql server (normal
as
> I have a table that is a bit to wide), bu the message box that SQL Compare
> used to display the warnings was at least 5 feet high;). (but it close OK
> with the enter key).
>
>
> Much to my regret my display isn't that big (yet). Maybe use a scrollable
> textarea to display errors & warnings.
>
> have a nice day.
>
> Eric
>
> "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
> news:Ymsvin0WDHA.2008@server53...
> > Hi Eric,
> >
> > There seems to be a bug in the new SQL Data Compare, then. If your
> text
> > contains backslashes and carriage returns, the backslashes are not
> > surrounded in quotes as they should be and SQL Server will treat them
like
> > continuation lines. We'll get this fixed as soon as possible.
> >
> > Thanks for contacting us about this.
> >
> > Regards,
> > Brian Donahue
> > Red Gate Software Support
> >
> > "lakusha@excite.com" <Lakusha@excite.com> wrote in message
> > news:l4ISUp4VDHA.1488@server53...
> > > Hi Brian,
> > >
> > > I *think* I've I've identified the source of the problem.
> > > I've found the following info in the "Embedded SQL for C and SQL
Server"
> > > section of BOL:
> > >
> > > --- quote ---
> > > You can use a backslash () to continue Embedded SQL strings across
more
> > > than one line of source code. A single quotation mark must precede the
> > first
> > > character of the Embedded SQL string on the first line of source code,
> and
> > a
> > > single quotation mark must appear after the last character of the
string
> > on
> > > the last line of source code. For example:
> > >
> > > EXEC SQL INSERT INTO TEXT132 VALUES ('TEST 192 IS THE TEST FOR THE R> > > ULE OF THE CONTINUATION OF LINES FROM ONE LINE TO THE NEXT LINE.');---
> end
> > > quote ---
> > >
> > > So the problem happen only when the text have + return in it. You
can
> > > reproduce it with this:
> > >
> > > a) Insert into #test(tText) select 'test> > > aaa'
> > >
> > > Select tText from #test
> > >
> > > tText
> > >

---

> > > testaaa <---- Missing + return
> > >
> > > But the following script fixes the problem:
> > >
> > > Insert into #test(tText) select 'test> > >
> > > aaa'
> > >
> > > I don't know if there is another workaround to this. I'm still
> > > investigating.
> > >
> > > Eric
> > >
> > >
> > > "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in
message
> > > news:UYPYpY4VDHA.1488@server53...
> > > > Hi Eric,
> > > >
> > > > Thanks for writing. Your problem with SQL Data Compare is not a
> > known
> > > > problem, but give me a day of so to run a test against SQL Data
> Compare
> > > and
> > > > I'll try to acqaint myself with it a bit better. :-)
> > > >
> > > > Brian Donahue
> > > > Red Gate Technical Support
> > > >
> > > > "lakusha@excite.com" <Lakusha@excite.com> wrote in message
> > > > news:BD0I%23NuVDHA.1520@server53...
> > > > >
> > > > > Hello,
> > > > >
> > > > > I've noticed that Text fields can now be compared (version 3). So
> > > there's
> > > > no
> > > > > more "incomparable columns". But there seem to be problems with
text
> > > > > comparisons.
> > > > >
> > > > > a) I update an empty db with the generated script
> > > > > b) a second compare is done automatically but many records differ.
> > > > >
> > > > > I think the difference is the text columns. When I click on a text
> > link
> > > in
> > > > > the Different Records tab the text displayed are different. There
> are
> > a
> > > > few
> > > > > missing in the updated text field. Is this a known problem with
> SQL
> > > > > DataCompare 3.0?
> > > > >
> > > > > regards,
> > > > >
> > > > > Eric
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>