Re: Crash in Art-s dbcopy
Except dbcopy doesn't use deferred PREPARE or OPTOFC. It does use
FetArrSize though.
The very odd thing is that with the column sized at 6546 with the SERIAL
column I also included in the test, the rowsize is 6550.
A maximum FetBufSize buffer of 32767 bytes will hold 5 such rows, but it
will also hold 5 rows of 6551 bytes....
Hmm, maybe with the column alignment ... Ya, assuming the alignment
adjustment to space out for the oddsized LVARCHAR caused dbcopy to bring the
required buffer size for the 6547 bytes column version up to 6554 and the
comm buffer will only hold 4.995 - ie four rows and I've set the FetArrBuf
for five rows. Might be the problem. I'll check it out. It's likely that
I've never tested with a rowsize that was sized such that the field
alignment caused the buffers to be too big.
Dirk, can you verify what your rowsize is for the dbcopy that's failing?
Art
On Sun, Aug 17, 2008 at 6:21 PM, Jonathan Leffler
<jleffler.iiug@gmail.com>wrote:
> 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.
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do those
opinions reflect those of other individuals affiliated with any entity with
which I am affiliated nor those of the entities themselves.