Powerbuilder 6.5 & SQL-server 6.5 <> 7.0

Hi everyone,
I'm using PB 6.5 with SQS 6.5
Everything is normal until I port the program build in this environment to 
a similar environment with the only difference that the database is SQS 7.0
This database is slightly different - in some tables, the fields are larger 
than in the SQS 6.5 database (but the same type - char).
When the program retrieves rows in that environment I get the error message 
'Data conversion resulted in overflow ...'
I have several other environments with sqs 6.5 with the same difference 
(larger fields) where the program doesn't report the error.
Does this sound familiar to someone ?
Thx for helping ...
Jurgen.
0
Jurgen_Cauwenbergh
6/13/2001 2:18:28 PM
📁 sybase.powerbuilder.datawindow
📃 28057 articles.
⭐ 5 followers.

💬 6 Replies
👁️‍🗨️ 1323 Views


1) If you are using native drivers to connect to MS SQS 7, do not create
columns of type char() or varchar() > 255
2) The error might come of a different way of padding char/varchar columns
between SQL 6.5 and SQS 7.
When you compare results between SQLS 7 and SQS 6.5, do both
server/databases have the same data?
I ask this question because I'm not sure your 'Data conversion resulted in
overflow ...' error comes from SQS 7:
Let say you have in your db a char() column of size 40.  Also, the
corresponding colum in your datawindow is size only for 30 chars.
You will get an overflow error only if a row has more than 30 chars.  If all
the rows have a column made of <= 30 chars, you will not get the error.
To force PB to reevaluate the column sizes is painful.  Here is what I do:
    1. Open datawindow object
    2. Go to the painter displaying the SQL supporting the datawindow
    3. Add a fake column or computed field (generally I just type 1 in the
1st computed field available in the list).
    4. Quit SQL painter and go back to the main datawindow design painter
    5. Go back to the painter displaying the SQL
    6. Undo the change you did in 3.
    7. Go back to main datawindow design painter
    8. Save
Step 3. is very important.  Things can get even more complicated if your
datawindow has modified update properties...
If you know a better way of doing it please let me know.
Xavier
If somebody knows a better way,
<Jurgen_Cauwenbergh> wrote in message
news:A20368F64D1DD64D004E984985256A6A.004E985785256A6A@webforums...
> Hi everyone,
>
> I'm using PB 6.5 with SQS 6.5
> Everything is normal until I port the program build in this environment to
> a similar environment with the only difference that the database is SQS
7.0
>
> This database is slightly different - in some tables, the fields are
larger
> than in the SQS 6.5 database (but the same type - char).
>
> When the program retrieves rows in that environment I get the error
message
> 'Data conversion resulted in overflow ...'
>
> I have several other environments with sqs 6.5 with the same difference
> (larger fields) where the program doesn't report the error.
>
> Does this sound familiar to someone ?
> Thx for helping ...
> Jurgen.

0
Xavier
6/13/2001 3:54:30 PM
if you have varchar columns greater than 255 then you need to change the sql
in your datawindows to say cast(yourcolumn as text) as yourcolumn. That way
the limit is increased to 32,000.
an easier way to get PB to accept your dw changes is to add a space anywhere
in the SQL then save it. Thus, you don't have to add the dummy column. This
applies only if you choose to have SQL as syntax in the datawindow (I pretty
much always do...)
--
Kim Berghall
Sisu Group, Inc.
remove no_spam.
no_spam.kberghall@sisugrp.com
www.sisugrp.com
"Xavier Colmant" <xcolmant@powerir.com> wrote in message
news:SUf4hRC9AHA.85@forums.sybase.com...
> 1) If you are using native drivers to connect to MS SQS 7, do not create
> columns of type char() or varchar() > 255
> 2) The error might come of a different way of padding char/varchar columns
> between SQL 6.5 and SQS 7.
>
> When you compare results between SQLS 7 and SQS 6.5, do both
> server/databases have the same data?
>
> I ask this question because I'm not sure your 'Data conversion resulted in
> overflow ...' error comes from SQS 7:
> Let say you have in your db a char() column of size 40.  Also, the
> corresponding colum in your datawindow is size only for 30 chars.
> You will get an overflow error only if a row has more than 30 chars.  If
all
> the rows have a column made of <= 30 chars, you will not get the error.
>
> To force PB to reevaluate the column sizes is painful.  Here is what I do:
>     1. Open datawindow object
>     2. Go to the painter displaying the SQL supporting the datawindow
>     3. Add a fake column or computed field (generally I just type 1 in the
> 1st computed field available in the list).
>     4. Quit SQL painter and go back to the main datawindow design painter
>     5. Go back to the painter displaying the SQL
>     6. Undo the change you did in 3.
>     7. Go back to main datawindow design painter
>     8. Save
> Step 3. is very important.  Things can get even more complicated if your
> datawindow has modified update properties...
>
> If you know a better way of doing it please let me know.
>
> Xavier
> If somebody knows a better way,
> <Jurgen_Cauwenbergh> wrote in message
> news:A20368F64D1DD64D004E984985256A6A.004E985785256A6A@webforums...
> > Hi everyone,
> >
> > I'm using PB 6.5 with SQS 6.5
> > Everything is normal until I port the program build in this environment
to
> > a similar environment with the only difference that the database is SQS
> 7.0
> >
> > This database is slightly different - in some tables, the fields are
> larger
> > than in the SQS 6.5 database (but the same type - char).
> >
> > When the program retrieves rows in that environment I get the error
> message
> > 'Data conversion resulted in overflow ...'
> >
> > I have several other environments with sqs 6.5 with the same difference
> > (larger fields) where the program doesn't report the error.
> >
> > Does this sound familiar to someone ?
> > Thx for helping ...
> > Jurgen.
>
>

0
Kim
6/13/2001 6:18:56 PM
"Kim Berghall" <kberghall@sisugrp.com> wrote in message
news:IA0qshD9AHA.85@forums.sybase.com...
> if you have varchar columns greater than 255 then you need to change the
sql
> in your datawindows to say cast(yourcolumn as text) as yourcolumn. That
way
> the limit is increased to 32,000.
>
> an easier way to get PB to accept your dw changes is to add a space
anywhere
> in the SQL then save it. Thus, you don't have to add the dummy column.
This
> applies only if you choose to have SQL as syntax in the datawindow (I
pretty
> much always do...)
>
Kim,
Thanks for your tips, although your way of forcing PB to reassess the column
lenghts is still lenghty...  Anybody knows a faster trick?
Xavier

0
Xavier
6/14/2001 12:47:13 PM
There is none... but my solution is very quick and easy to do...
--
Kim Berghall
Sisu Group, Inc.
remove no_spam.
no_spam.kberghall@sisugrp.com
www.sisugrp.com
"Xavier Colmant" <xcolmant@powerir.com> wrote in message
news:xe8dkNN9AHA.301@forums.sybase.com...
> "Kim Berghall" <kberghall@sisugrp.com> wrote in message
> news:IA0qshD9AHA.85@forums.sybase.com...
> > if you have varchar columns greater than 255 then you need to change the
> sql
> > in your datawindows to say cast(yourcolumn as text) as yourcolumn. That
> way
> > the limit is increased to 32,000.
> >
> > an easier way to get PB to accept your dw changes is to add a space
> anywhere
> > in the SQL then save it. Thus, you don't have to add the dummy column.
> This
> > applies only if you choose to have SQL as syntax in the datawindow (I
> pretty
> > much always do...)
> >
> Kim,
>
> Thanks for your tips, although your way of forcing PB to reassess the
column
> lenghts is still lenghty...  Anybody knows a faster trick?
>
> Xavier
>
>

0
Kim
6/14/2001 3:39:48 PM
Thank you both for all the answers.
I thought it was something like that, but hoped that there was another 
(quicker) solution for it - because there are hundreds of dw to be changed.
There are 4 different servers (2 of them have SQS 6.5 and 2 of them have 
SQS 7)
There is a table which has a field with a length that is different on each 
server ( char(30), char(35), char(40) and char(45) )
I once changed this quickly (I'm a bit lazy) when the users requested more 
characters for that field.
But now I have changed the fields all the same size on each server to 
char(50), but now I need to update all my datawindows to accept the 50-char 
length
Thx !
0
Jurgen_Cauwenbergh
6/15/2001 9:59:33 AM
There is still another "gotcha" that you might have to check in addition to
open the SQL painter and make a dummy modification. You may have to check
the edit limit field. You should be alright if it says 0 (limited to the
field length), but if it says 35 or 40 then you need to change it to 50.
Otherwise the users will not be able to enter 50 chars...
This is one of those, "just bite the bullet and do it" things...
--
Kim Berghall
Sisu Group, Inc.
remove no_spam.
no_spam.kberghall@sisugrp.com
www.sisugrp.com
<Jurgen_Cauwenbergh> wrote in message
news:1AA7A84A8E7CCAE60036E42C85256A6C.005A63F185256A6B@webforums...
> Thank you both for all the answers.
>
> I thought it was something like that, but hoped that there was another
> (quicker) solution for it - because there are hundreds of dw to be
changed.
>
> There are 4 different servers (2 of them have SQS 6.5 and 2 of them have
> SQS 7)
>
> There is a table which has a field with a length that is different on each
> server ( char(30), char(35), char(40) and char(45) )
>
> I once changed this quickly (I'm a bit lazy) when the users requested more
> characters for that field.
>
> But now I have changed the fields all the same size on each server to
> char(50), but now I need to update all my datawindows to accept the
50-char
> length
>
> Thx !

0
Kim
6/15/2001 4:23:55 PM
Reply: