urn:lsid:ibm.com:blogs:entrycomments-36c22388-c1c0-41a2-834e-59f283af5d00Size matters: A handy routine to compute the defined row size of a table (Comentários)Size matters: A handy routine to compute the defined row size of a table (Comentários)03092015-12-04T09:01:18-05:00IBM Connections - Blogsurn:lsid:ibm.com:blogs:comment-e8d6bb6b-4b45-42bb-9076-e6fd631b7ccaRef.: Size matters: A handy routine to compute the defined row size of a tableSergeRielau120000D76FactivefalseSergeRielau120000D76FactivefalseCurtir2014-01-21T10:01:58-05:002014-01-21T10:01:58-05:00Kelly,
This is odd.I don't think any of the potential reasons you guess at (UTF-8, DataStudio or stats) can have any impact on the function.
Reason being that it is written in SQL PL and thus datastudio won't be abel to do any harm to it.
All it does is to pass the text along to DB2.
The values the function looks at are also the defined lengths and not anything gleaned from statistics.
Perhaps it was function overloading that did you in? A previous attempt at the function with similar signature?
Glad you got it to work though.
Cheers
SergeKelly,
This is odd.I don't think any of the potential reasons you guess at (UTF-8, DataStudio or stats) can have any impact on the function.
Reason being that it is written in SQL PL and thus datastudio won't be abel to do any harm to it.
All it does is t...falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-e19ad328-d26b-4ba9-8044-992cffedb1d5Ref.: Size matters: A handy routine to compute the defined row size of a tableKpfitzgerald270001UJMAactivefalseKpfitzgerald270001UJMAactivefalseCurtir2014-01-20T10:48:33-05:002014-01-20T10:48:33-05:00Well i got it working... not sure how or why... My best guess is running statistics after deploying the UDF. I had stats prior, not sure if its a MUST to run after seems to be the only real fix i can think of, i did mess with the deployment parameters also, but that was just removing the debug from the deploy and using db2admin instead of anther user account with admin rights.Well i got it working... not sure how or why... My best guess is running statistics after deploying the UDF. I had stats prior, not sure if its a MUST to run after seems to be the only real fix i can think of, i did mess with the deployment parameters also, bu...falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-48900ce7-7e92-4759-9591-9b951a6be4f5Ref.: Size matters: A handy routine to compute the defined row size of a tableKpfitzgerald270001UJMAactivefalseKpfitzgerald270001UJMAactivefalseCurtir2014-01-20T09:29:41-05:002014-01-20T09:29:41-05:00Hey Serge and Rick,
So I added the function to my 10.1 DB (hybrid OLTB) on windows 7 box, (internal dev system), and finally figured out how to do this on Data Studio 4.1. All good!
I run the query to get a listing of the row sizes, and walla! all 0's. Not sure if there is a casting issue or an encoding issue (UTF-8). Im pretty new to functions (only done 3 in my lifetime), and DS4.1 is really not being very user friendly on finding the "opportunity".
any Words of advice, or insight you can pass would be greatly appreciated. If you need further details or need to move this to a forum or email let me know.
Thanks
FitzHey Serge and Rick,
So I added the function to my 10.1 DB (hybrid OLTB) on windows 7 box, (internal dev system), and finally figured out how to do this on Data Studio 4.1. All good!
I run the query to get a listing of the row sizes, and walla! all 0's....falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-2a4197a5-c6f7-4233-8c8b-35978e06982fRef.: Size matters: A handy routine to compute the defined row size of a tableSergeRielau120000D76FactivefalseSergeRielau120000D76FactivefalseCurtir2013-04-05T09:28:44-04:002013-04-05T09:28:44-04:00Feng Piao,
You are correct. Also the code in question is not safe in compatibility mode since division of integers returns a DECFLOAT in NUMBER mode.
I have updated the code in the article to
TRUNC(length / 2) + 1
Thanks for finding the bug.
SergeFeng Piao,
You are correct. Also the code in question is not safe in compatibility mode since division of integers returns a DECFLOAT in NUMBER mode.
I have updated the code in the article to
TRUNC(length / 2) + 1
Thanks for finding the bug.
SergefalsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-c60f67cb-20b7-407b-b88e-01f0b4b01944Ref.: Size matters: A handy routine to compute the defined row size of a tableFeng WanLi2700052EYBactivefalseFeng WanLi2700052EYBactivefalseCurtir2013-04-05T03:04:12-04:002013-04-05T03:04:12-04:00I READ THE IBM DB2 INFORMATION CENTER, THAT SAY ,THE DECIMAL IS " p/2+1 bytes, where p is precision " .I READ THE IBM DB2 INFORMATION CENTER, THAT SAY ,THE DECIMAL IS " p/2+1 bytes, where p is precision " .falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-385fbfd7-f71c-441d-99b0-e496440b79a5Ref.: Size matters: A handy routine to compute the defined row size of a tableSergeRielau120000D76FactivefalseSergeRielau120000D76FactivefalseCurtir2013-01-16T07:11:15-05:002013-01-16T07:11:15-05:00현 지수,
While it is correct that LOBs are not part of the row, DB2 must maintain "pointers" to these LOB values.
You can see in the "loblength" variable assignment how the pointer gets longer as the maximum size increases.
A 2GB LOB can still consume over 300 bytes within the row..
Cheers
Serge
현 지수,
While it is correct that LOBs are not part of the row, DB2 must maintain "pointers" to these LOB values.
You can see in the "loblength" variable assignment how the pointer gets longer as the maximum size increases.
A 2GB LOB can still consume over...falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-a04b8997-2d8a-4987-aaee-aaf2a11df734Ref.: Size matters: A handy routine to compute the defined row size of a table0UNX_현_지수2700010UNXactivefalse0UNX_현_지수2700010UNXactivefalseCurtir2013-01-16T03:49:59-05:002013-01-16T03:49:59-05:00SergeRielau,
Thank you for sharing useful infomation.
I konw LOB types are not include in the page limit.
Why function include LOB types?
SergeRielau,
Thank you for sharing useful infomation.
I konw LOB types are not include in the page limit.
Why function include LOB types?
falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-b284248e-e951-46d3-b4d4-7062e6e3a54dRef.: Size matters: A handy routine to compute the defined row size of a tableSergeRielau120000D76FactivefalseSergeRielau120000D76FactivefalseCurtir2012-12-10T21:58:56-05:002012-12-10T21:58:56-05:00Patrick,
Wouldn't be the first function that starts in this blog and ends in the product.
Consider it an alpha release.
Cheers
SergePatrick,
Wouldn't be the first function that starts in this blog and ends in the product.
Consider it an alpha release.
Cheers
SergefalsefalseRE: Size matters: A handy routine to compute the defined row size of a table0urn:lsid:ibm.com:blogs:comment-8eff2ce1-4efe-42e6-abc8-53073abca9e3Ref.: Size matters: A handy routine to compute the defined row size of a tablePatrick Dantressangle1200007665activefalsePatrick Dantressangle1200007665activefalseCurtir2012-12-10T16:42:30-05:002012-12-10T16:42:30-05:00Why isn't this procedure shipped by default with DB2 ? Why isn't this procedure shipped by default with DB2 ? falsefalseRE: Size matters: A handy routine to compute the defined row size of a table0