Closed GoogleCodeExporter closed 9 years ago
Hi Bhornseth,
I understand the problem. This problem arises due to PyString_FromString()
detects
x'000' as string terminator.
If i use the method you provided, then I get correct result. But if you define a
field as “CHAR(13) FOR BIT ATA COLUMN” and insert a data which is less then
13 bytes
in length, then at the time of fetching you will get data of length 13 bytes
only as
database will always return data size as 13. So, the output would be your data
followed by spaces (x'20'). If you use VARCHAR(13) instead, then the database
will
return exact length and there wouldn't be any following spaces. I think you are
aware
of this problem .
Let me know what you think of this, I will take your views into consideration
while
fixing this.
Thanks,
Rahul Priyadarshi
Original comment by rahul.pr...@in.ibm.com
on 4 Mar 2010 at 11:15
Thanks for the informative reply, Rahul. I was aware of the caveat with data
that
was potentially shorter than the full column length, but I'm not familiar
enough with
the DB2 cli to implement a better solution, so I'll defer to your knowledge on
that. :)
I believe my naive patch will be alright for our situation as the only columns
of
this type we use /always/ contain 13 characters (we use the DB2
generate_unique()
function). Admittedly, the patch I provided is more of a workaround than a
solution.
I much appreciate any advice you're able to offer as an alternative, even if an
official patch takes a while.
Unfortunately, we have a couple hundred tables across several database servers
that
use this column type, and converting them to VARCHAR isn't an immediate option
for
us. We'll definitely look into using this for new tables in the meantime.
Original comment by bhorns...@gmail.com
on 4 Mar 2010 at 4:14
For the CHAR fields, if data is shorter than column length , you will always
get data
of fixed length followed by spaces. For more info refer to this link
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.db
conn.doc/doc/c0006171.html
.
If you want data with actual length then you must have to use VARCHAR. In your
case
CHAR is more more efficient.
It will be available with our next release.
Thanks,
Rahul Priyadarshi
Original comment by rahul.pr...@in.ibm.com
on 5 Mar 2010 at 12:29
Fixed in ibm_db-1.0.1
Original comment by rahul.pr...@in.ibm.com
on 27 Mar 2010 at 8:41
Thanks for the quick turnaround, folks. This is working well.
Original comment by bhorns...@gmail.com
on 31 Mar 2010 at 8:52
Original issue reported on code.google.com by
bhorns...@gmail.com
on 1 Mar 2010 at 9:39Attachments: