Front page | perl.dbi.users |
Postings from January 2007
Mickautsch, Alfred wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Martin Evans [mailto:martin.evans@easysoft.com]
>> Gesendet: Dienstag, 30. Januar 2007 10:44
>> An: dbi-users@perl.org
>> Betreff: Re: AW: Re: AW: CLOB Problem with DBD::ODBC/DBD::ADO for SQL
>> Server
> [...]
>> what version of sql server are you using?
>> what version of the sql server odbc driver are you using?
>> have you got any settings in the odbc dsn changed from default?
>>
> [...]
> SQL Server: Microsoft SQL Server 2005 Version 9.00.1399.06
> ODBC Driver: SQL Native Client Version 2005.90.1399.00
> I do not use a dsn, I use a connect string like the following:
> 'Driver={SQL Native Client};Server=schuler-sql01;Database=coedev03'
> There are no other settings in the string.
>
> Servus -- Alfred
>
> --
> Alfred Mickautsch
and previously you said:
> When inserting data (ASCII data which comes from a Oracle CLOB) into a
> NCLOB on SQL Server, backslashes at the end of a line seem to be
> interpreted as escape characters and the backslash and the following
> newline are removed from the data.
I'm sorry Alfred but I just can't reproduce exactly what you describe. I
lose no back slashes (other than those perl would remove if not using a
single quoted string) and no line feeds.
I have now got script running on Windows xp, active state perl 5.8.8
build 819, DBI 1.52, DBD::ODBC 1.13. When I run the following script:
use DBI;
$h = DBI->connect("dbi:ODBC:XXX","xxx", "yyy");
$s = $h->prepare(q/insert into test_char values(?)/);
$f = <<_'EOF';
\\\\
\\\\
\\\\
\\\\
_EOF
$s->execute($f);
print "length=", length($f);
$x = $h->selectrow_arrayref(q/select * from test_char/);
print "length=", length($x->[0]);
I insert 24 chars (16 \ and 8 line feeds) and I get back 24 chrs.
I am unsure why the code does not insert CR\LF as I am 100% sure the
file itself contains CR\LF.
I have tried with ntext, text and char fields - no difference.
I have run it through a tds spy and can see the line feeds going through
fine in both directions.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Thread Previous