Re: Crash in Art-s dbcopy
On Sun, Aug 17, 2008 at 12:30 PM, Art Kagel <art.kagel@gmail.com> wrote:
> It would seem to be a bug in the ESQL/C library or IDS itself. I have just
> finished extensive testing. Dbcopy works fine for LVARCHAR columns as long
> as the length of the column is 6,546 bytes or less. I was sure that I'd
> tested LVARCHARs when I added support for them 8-). I will open a case with
> IBM on Monday to track this. Thanks for reporting it Dirk.
>
> Note from 6547 bytes to about 10,000 bytes dbschema gets the undocumented
> error -1831. From about 10,000 bytes and up it does SEGV while fetching the
> first row, but that may just be a more severe symptom of the same bug.
FWIW, I have:
Black JL: chkmsg -1831
-1831: Combination of FetArrSize Deferred-PREPARE and OPTOFC is not supported.
Black JL:
I'm not sure what that has to do with the problem...
Art - testing with CSDK 3.50.FC1 and IDS 11.50.FC1 on Solaris 10 (and
SQLCMD 86.00), I used this test script:
sqlcmd -C -d stores 'create table lvc(lvc lvarchar(20000) not null, s
serial not null primary key)'
perl -e '
my(@list) = (1, 10, 100, 1000, 6000, 6300, 6400, 6500, 6600,
6700, 6800, 6900, 7000, 8000, 9000, 10000, 11000,
12000, 19000, 19999, 20000, 20001);
foreach my $i (@list)
{
print "X" x $i, "|0|\\n";
}' |
sqlcmd -R -d stores -t lvc -N 1
sqlcmd -U -d stores -t lvc -O s |
awk -F'|' '{print length($1);}'
The output from that script was:
Black JL: ksh -x test.lvc.sh
+ sqlcmd -C -d stores create table lvc(lvc lvarchar(20000) not null, s
serial not null primary key)
+ perl -e
my(@list) = (1, 10, 100, 1000, 6000, 6300, 6400, 6500, 6600,
6700, 6800, 6900, 7000, 8000, 9000, 10000, 11000,
12000, 19000, 19999, 20000, 20001);
foreach my $i (@list)
{
print "X" x $i, "|0|\\n";
}
+ sqlcmd -R -d stores -t lvc -N 1
1 rows committed
2 rows committed
3 rows committed
4 rows committed
5 rows committed
6 rows committed
7 rows committed
8 rows committed
9 rows committed
10 rows committed
11 rows committed
12 rows committed
13 rows committed
14 rows committed
15 rows committed
16 rows committed
17 rows committed
18 rows committed
19 rows committed
20 rows committed
21 rows committed
22 rows committed
+ sqlcmd -U -d stores -t lvc -O s
+ awk -F| {print length($1);}
1
10
100
1000
6000
6300
6400
6500
6600
6700
6800
6900
7000
8000
9000
10000
11000
12000
19000
19999
20000
20000
Black JL:
While this is by no means conclusive proof that there is not a problem
on some platforms, or with some versions of IDS, it does suggest that
there are some platforms where LVARCHAR(20000) works OK.
> On Sun, Aug 17, 2008 at 12:50 PM, Dirk B. <tohoNOSPAM@myrealbox.com> wrote:
>> I-m migration a database from Solaris 2.8 9.40FC5 to Suse 11.50FC1 using
>> Art's dbcopy program. It crashes on every table that has a
>> lvarchar-column with "code -1831". I can-t even find this error-code ...
>> All other tables work fine.
>> Has anyone successfully transferred tables with lvarchars and dbcopy?
>> Or an idea what might causing the crash?
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
"Blessed are we who can laugh at ourselves, for we shall never cease
to be amused."
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.